TL;DR: The Quick Fix
This error pops up when Redis gets a request that doesn't follow the RESP (Redis Serialization Protocol) format. It usually means the length prefix for a bulk string (the part starting with $) is missing, wrong, or not a valid number.
- Using Telnet or Netcat? You must follow the exact RESP format. A simple
GET keywon't work in raw mode; you need*2\r\n$3\r\nGET\r\n$4\r\nkey1\r\n. - Seeing this in a Browser? You are likely sending HTTP traffic to the Redis port. Redis doesn't speak HTTP.
- Using a Client Library? Check your data size. Ensure you aren't exceeding the
proto-max-bulk-len, which defaults to 512MB.
Why This Error Happens
Redis speaks a language called RESP. When you send a command, Redis expects a strict structure. A "bulk string" starts with a $ character, followed by the exact number of bytes in that string, a CRLF (\r\n), the data itself, and another CRLF.
The ERR Protocol error: invalid bulk length triggers if the character after the $ isn't a number. Redis kills the connection immediately. It does this to protect itself from memory corruption or buffer overflows caused by garbage data.
Common Scenarios and Solutions
1. Manual Commands via Telnet or Netcat
Testing Redis manually is great, but typing commands as plain text often fails. Redis has an "inline command" mode for simple requests like PING. However, complex operations require proper RESP formatting.
The Mistake:
$ telnet localhost 6379
$ SET mykey
# If you type $ followed by text instead of a number:
$invalid_length
-ERR Protocol error: invalid bulk length
The Fix: Stick to redis-cli for manual testing. If you must use Telnet, use the full RESP structure. For example, to set "name" to "John", you need to send the exact byte count for every piece of the command.
# Full RESP format
*3
$3
SET
$4
name
$4
John
2. Accidental HTTP Requests
This error frequently fills logs when a web browser or security scanner hits port 6379. An HTTP request starts with GET / HTTP/1.1. Redis sees that / or the headers and tries to parse them as RESP. It fails instantly.
The Fix:
- Check your
REDIS_URLenvironment variables. Make sure they don't accidentally point to a web service. - Audit your load balancer health checks. Tools like AWS ELB or Kubernetes Liveness Probes should use a Redis-compatible check, not a raw HTTP GET.
3. Encoding and Serialization Bugs
Custom or older client libraries in languages like C or Go sometimes miscalculate string lengths. This is common with multi-byte characters like UTF-8 emojis or Vietnamese text.
If your library counts characters instead of bytes, the math won't add up. Redis expects the byte count. If the declared length is 8 but the actual payload is 9 bytes, the protocol breaks.
The Fix:
- Always use
Buffer.byteLength()or its equivalent rather thanstring.length. - Update your Redis client to the latest stable version.
Node.js Example:
const val = "Xin chào";
console.log(val.length); // 8 (Wrong for Redis!)
console.log(Buffer.byteLength(val)); // 9 (Correct!)
4. Massive Payloads
While this error usually signals a formatting bug, it can happen if a client sends an impossibly large length value. Redis won't even try to parse a request if the header claims the data is larger than the server can handle.
The Fix: Check your redis.conf for the proto-max-bulk-len limit. The default is 512MB. If you need to store larger files, split the data into chunks or use APPEND to build the value incrementally.
# Check your current limit via CLI
CONFIG GET proto-max-bulk-len
How to Verify the Fix
You need to see exactly what the client is sending. Use ngrep to sniff raw traffic hitting your Redis server. It’s the fastest way to spot malformed data.
Run this command to watch incoming traffic:
sudo ngrep -W byline -d any port 6379
Keep an eye on the $ signs. If you see $NaN, $-5, or $ followed by text, your client code is broken. A healthy request looks like a clean stack of stars and dollar signs. Once the protocol is fixed, the errors will stop and your client will receive the standard +OK response.