Proxy_pass with / in the end causes SYN packets?

Projects NGINX
, ,
1

Hi, now i’m making Reverse Proxy by using Nginx1.25.3(openresty1.25.3.1),
i have one backend
backend1:192.168.62.60

that has no content_path so i set up nginx.conf like below.
and i wanna have other backends so give it a location keyword in the request uri as “/backend1”,
and call proxy_pass with / in the end(remove “/backend1” from request_uri).

then when i was looking into the packets between Nginx and backend1 with WireShark,
i’ve noticed that SYN packets are increased than when i connected directly from browser to backend1.

heard many suggestions that Keep-Alive may be involved, so i tried the parameters related to it, but there was no change.

In the WireShark view,
Connection parameter in the sent HTTP request, are always set as “Keep-Alive”,
but Nginx always sends FIN,ACK packet at the end of each tcp sequence started by one HTTP request from it’s side.

Any suggestion, please.
Thanks in advance.

Best regards. Yasoo7964

---- nginx.conf ---------

http {
  upstream backend1_server {
    server 192.168.62.60;
    keepalive 32;
  }
  server {
    listen 80;
    
    listen 443 ssl;
    ssl_certificate          /etc/ssl/rootCA/gw.com/certs/gw.com.crt.pem;
    ssl_password_file        /etc/ssl/rootCA/gw.com/pwf;
    ssl_certificate_key      /etc/ssl/rootCA/gw.com/private/privkey.pem;
    
    server_name              192.168.52.111;
    proxy_http_version       1.1;
    proxy_set_header         Upgrade           $http_upgrade;
    proxy_set_header         Connection        "Keep-Alive";
    proxy_set_header         Host              $host;
    proxy_set_header         X-Real-IP         $remote_addr;
    proxy_set_header         X-Forwarded-For   $proxy_add_x_forwarded_for;
    proxy_set_header         X-Forwarded-Proto $scheme;
    
    keepalive_timeout        60s;
    keepalive_requests       100;
    proxy_connect_timeout    5s;
    proxy_read_timeout       60s;
    
    proxy_max_temp_file_size 0;
    sendfile                 off;
    etag                     off;
    if_modified_since        off;
    
    location /backend1/ {
      proxy_pass        http://backend1_server/;
      proxy_redirect    / /backend1/;
      
      header_filter_by_lua_block {
        rewrite_resp.header_filter()
      }
      body_filter_by_lua_block {
        rewrite_resp.body_filter(ngx.var.scheme, ngx.var.server_name,  "backend1")
      }
    }
  }
}
2 Likes
2

Moved this to the Troubleshooting category.

1 Like
3

Note: I asked this question because GPT said, ``Adding / to the end of proxy_pass, in other words, rewriting the HTTP request, may increase the number of SYN packets.‘’

1 Like
4

with further investigation, i found that backend1 does not support HTTP/1.1, so even though Nginx sends HTTP/1.1 request, backend1 always reply “HTTP/1.0 200 OK”.
In HTTP/1.0, it is correct behavior to create a new socket for each request.
sorry for asking an irrelevant question.

On the other hand, when i directly connect to backend1 with Edge,
Edge does not send FIN,ACK even when it receives “HTTP/1.0 200 OK”, and reuses the socket.

so i look into the “HTTP/1.0 200 OK”, it attached “Connection:Keep-Alive” option.
and i’ve heard that even in HTTP/1.0, it can reuse the socket with the option.

Does Nginx not support it?

5

If you upstream service does not support HTTP/1.1, you should remove the proxy_http_version 1.1; from your configuration, as this is setting communication for the upstream to use version 1.1. Without this directive, nginx will default to using HTTP/1 when proxying traffic to the upstream.

6

Thank you Damian,

i’ve tried it so Nginx sends GET xxxx HTTP/1.0 with Connection:Keep-Alive,
and then upstream replies as HTTP/1.0 200 OK with Connection:Keep-Alive,
but Nginx replies with FIN,ACK to it.

627 12.026094427 192.168.62.111 192.168.62.60 TCP 74 0 51946 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=1540337777 TSecr=0 WS=128
628 12.027588129 192.168.62.60 192.168.62.111 TCP 62 0 80 → 51946 [SYN, ACK] Seq=0 Ack=1 Win=14600 Len=0 MSS=1460 SACK_PERM=1
629 12.027961381 192.168.62.111 192.168.62.60 TCP 54 1 51946 → 80 [ACK] Seq=1 Ack=1 Win=64240 Len=0
630 12.029281992 192.168.62.111 192.168.62.60 HTTP 792 1 GET /date.htm HTTP/1.0

GET /date.htm HTTP/1.0\r\n
Connection: Keep-Alive\r\n

631 12.030395246 192.168.62.60 192.168.62.111 TCP 60 1 80 → 51946 [ACK] Seq=1 Ack=739 Win=15498 Len=0
632 12.030633835 192.168.62.60 192.168.62.111 TCP 238 1 80 → 51946 [PSH, ACK] Seq=1 Ack=739 Win=15498 Len=184 [TCP segment of a reassembled PDU]
633 12.030667413 192.168.62.111 192.168.62.60 TCP 54 739 51946 → 80 [ACK] Seq=739 Ack=185 Win=64056 Len=0
634 12.030814113 192.168.62.60 192.168.62.111 HTTP 1292 185 HTTP/1.0 200 OK (text/html)

HTTP/1.0 200 OK\r\n
Connection: Keep-Alive\r\n

635 12.030824244 192.168.62.111 192.168.62.60 TCP 54 739 51946 → 80 [ACK] Seq=739 Ack=1423 Win=64056 Len=0
636 12.030895231 192.168.62.111 192.168.62.60 TCP 54 739 51946 → 80 [FIN, ACK] Seq=739 Ack=1423 Win=64056 Len=0
637 12.031795309 192.168.62.60 192.168.62.111 TCP 60 1423 80 → 51946 [FIN, ACK] Seq=1423 Ack=740 Win=15498 Len=0
638 12.031829625 192.168.62.111 192.168.62.60 TCP 54 740 51946 → 80 [ACK] Seq=740 Ack=1424 Win=64056 Len=0

7

Hey @yasoo7964. Where you able to figure this out in the end?

8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.