Migrate ingress-nginx proxy-body-size to Envoy Gateway

If an Ingress uses nginx.ingress.kubernetes.io/proxy-body-size, there is no matching annotation to copy onto an HTTPRoute. Migrate ingress-nginx to Envoy Gateway does not carry that annotation across. On Envoy Gateway v1.9, a request body limit is BackendTrafficPolicy requestBuffer.limit.

The defaults are not the same either:

• ingress-nginx defaults proxy-body-size to 1m, which configures NGINX client_max_body_size.
• Envoy Gateway does not add requestBuffer to an HTTPRoute unless you configure it.
• With no such policy, the tested route accepted a 2097152 byte upload that ingress-nginx's default 1m limit rejected.

To keep an upload cap, add the policy and target the application HTTPRoute or the Gateway.

An oversized body is still HTTP 413. A custom error page can change the text, so the status alone is the portable fact. In this test the two bodies differed:

• Envoy's request-buffer rejection was plain text Payload Too Large.
• ingress-nginx returned an HTML page titled 413 Request Entity Too Large.

What replaces proxy-body-size in Envoy Gateway?

proxy-body-size and requestBuffer.limit both end in HTTP 413 for an oversized body. They are not the same mechanism.

10m and 10Mi are the same byte count here. ingress-nginx 1m allowed 1048576 bytes and rejected 1048577, so m on that controller is 1024 × 1024. 10Mi is 10 times that.

This is a behavior change, not a field rename:

• proxy-body-size sets NGINX client_max_body_size.
• Envoy Gateway's requestBuffer turns on full request buffering and uses that buffer as the maximum body size.

The annotation you are leaving behind looks like this. Do not copy it onto the HTTPRoute. Envoy Gateway does not read ingress-nginx annotations:

metadata:
  annotations:
    nginx.ingress.kubernetes.io/proxy-body-size: "10m"

ingress-nginx translates that annotation into client_max_body_size. The examples below assume an existing HTTPRoute named web that forwards to your application Service.

How Envoy Gateway requestBuffer.limit works

Once the policy is attached, the buffer behaves like this:

• A body at the limit is forwarded to the application.
• A body over the limit stops in the buffer and returns HTTP 413. The application does not see that request.
• On v1.9.2 the request buffer object has one field, limit. There is no separate mode switch.
• The limit counts the received body, not only the Content-Length header. A chunked body of 1024 bytes against a 1Ki limit returned 200, and 1025 bytes returned Payload Too Large.

requestBuffer waits for the complete request body and should not be used for streaming or upgrade traffic such as gRPC streaming and WebSocket. WebSocket disconnects covers that case on an upgraded connection.

Set a request body limit on one HTTPRoute

Target the policy at HTTPRoute web when only that application should be capped. 10Mi is a stand-in. Replace it with the maximum body your application should accept:

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: BackendTrafficPolicy
metadata:
  name: request-buffer
spec:
  targetRefs:
  - group: gateway.networking.k8s.io
    kind: HTTPRoute
    name: web
  requestBuffer:
    limit: 10Mi

Two fields do the work:

• targetRefs chooses the route. A Gateway target instead applies to every route on that Gateway.
• requestBuffer.limit is the cap, and it is also what turns buffering on.

The boundary below was checked with limit: 1Ki, so one extra byte is visible without an 11MiB upload. The attached policy reported Accepted=True:

kubectl get backendtrafficpolicy request-buffer -o jsonpath=\
'{range .status.ancestors[*].conditions[*]}{.type}={.status} {.reason}{"\n"}{end}'

Accepted=True Accepted

Accepted=True means the proxy took the policy. It does not mean a large upload has been tried yet.

Verify the upload limit

With this requestBuffer.limit configuration, a body equal to the limit reached the application, while one byte over returned HTTP 413. These captures used a local address for the Gateway. Send the same Host and body to the hostname your Gateway publishes.

With limit: 1Ki, a 1024 byte POST returned 200 and the application counted the body:

curl -sS -D - --max-time 15 -H 'Host: app.example.com' \
--data-binary @upload-1024.bin http://127.0.0.1:19080/upload

HTTP/1.1 200 OK
server: BaseHTTP/0.6 Python/3.12.15
date: Sat, 03 Oct 2026 19:52:57 GMT
content-type: text/plain
content-length: 11

bytes=1024

server: BaseHTTP/0.6 Python/3.12.15 means the application answered. The next body is 1025 bytes:

curl -sS -D - --max-time 15 -H 'Host: app.example.com' \
--data-binary @upload-1025.bin http://127.0.0.1:19080/upload

HTTP/1.1 413 Payload Too Large
content-length: 17
content-type: text/plain
date: Sat, 03 Oct 2026 19:52:56 GMT
connection: close

Payload Too Large

Read three things in that response:

• HTTP 413 is the body-size rejection.
• Plain text Payload Too Large came from Envoy's request buffer in this test. Treat it as the result here, not as a rule for every 413.
• No application server line means the application did not see this body.

ingress-nginx proxy-body-size: "1k" drew the same line: 1024 bytes returned 200, and 1025 bytes returned the nginx HTML 413 page.

Apply the request body limit to every route

Point targetRefs at the Gateway when every route should share the cap. The limit is still the maximum you chose. 10Mi below is the same stand-in as on the route:

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: BackendTrafficPolicy
metadata:
  name: request-buffer
spec:
  targetRefs:
  - group: gateway.networking.k8s.io
    kind: Gateway
    name: eg
  requestBuffer:
    limit: 10Mi

A Gateway target with requestBuffer.limit: 1Ki returned the same Payload Too Large response for a 1025 byte body, and that policy was also Accepted=True. Choose the target by scope:

• Gateway target when every route should share the cap.
• HTTPRoute target when only one application should be limited.

Why Envoy accepts an upload that ingress-nginx rejected

Do not assume the old nginx upload limit is still in force after the Ingress is gone. With no requestBuffer policy, Envoy Gateway accepted a 2097152 byte POST. curl received 100 Continue, then the application counted every byte:

curl -sS -D - --max-time 30 -H 'Host: app.example.com' \
--data-binary @upload-2m.bin http://127.0.0.1:19080/upload

HTTP/1.1 100 Continue

HTTP/1.1 200 OK
server: BaseHTTP/0.6 Python/3.12.15
date: Sat, 03 Oct 2026 19:51:56 GMT
content-type: text/plain
content-length: 14

bytes=2097152

That result shows this route accepted at least 2MiB. It does not show that every body size will succeed. Another filter that buffers a request can still return 413 when its own buffer is exceeded.

The same host through ingress-nginx, with the default body limit, allowed 1048576 bytes. One more byte was HTTP 413. The page in this test was nginx HTML:

curl -sS -D - --max-time 30 -H 'Host: app.example.com' \
--data-binary @upload-1m-plus.bin http://127.0.0.1:18080/upload

HTTP/1.1 413 Request Entity Too Large
Date: Sat, 03 Oct 2026 19:51:56 GMT
Content-Type: text/html
Content-Length: 176
Connection: close

<html>
<head><title>413 Request Entity Too Large</title></head>
<body>
<center><h1>413 Request Entity Too Large</h1></center>
<hr><center>nginx</center>
</body>
</html>

The nginx rejection came from client_max_body_size, which is what proxy-body-size configures. If the product still needs that cap, set requestBuffer.limit on Envoy. Leaving the policy off keeps the larger upload that nginx used to block.

requestBuffer.limit is not connection.bufferLimit

The connection buffer did not reject the upload in either check:

• The default connection buffer is 32768 bytes. The 2MiB upload above already succeeded with that default, before any request buffer existed.
• Setting connection.bufferLimit to 1024, with the request buffer removed, still returned 200 and bytes=2097152.

A Payload Too Large response in this test came from requestBuffer.limit.

Troubleshooting Envoy Gateway 413

Summary

proxy-body-size does not move onto an HTTPRoute. ingress-nginx uses it as client_max_body_size. Envoy Gateway v1.9 enforces a maximum body with BackendTrafficPolicy requestBuffer.limit, and turning that field on buffers the whole request before the application sees it. Use it for a size cap. Leave it off for WebSocket and gRPC streaming.

10m on the annotation and 10Mi on the policy are the same byte count to migrate. A 1Ki check allowed 1024 bytes and returned HTTP 413 for 1025. With no request buffer, a 2097152 byte upload returned 200, while ingress-nginx's default 1m rejected 1048577 bytes.

connection.bufferLimit did not become the upload cap. A value of 1024 still accepted the 2MiB body. Size that buffer when request buffering is on. It does not replace proxy-body-size.

References

• Envoy Gateway request buffering (v1.9)
• Envoy Gateway ClientTrafficPolicy (v1.9)
• ingress-nginx custom max body size