search

chobits / ngx_http_proxy_connect_module

A forward proxy module for CONNECT request handling
BSD 2-Clause "Simplified" License
1.75k stars 484 forks source link

The client received a RST (reset) package. #281

Closed guanzongjiang closed 3 months ago

guanzongjiang commented 11 months ago

CONNECT www.google.com:443 HTTP/1.1" 499 0 "-" "curl/7.79.1

hi， I have discovered a problem. 

curl https://www.google.com/ -v -x xxxxxx:8880
*   Trying xxxxxx:8880...
* Connected to xxxxxx (xxxxxx) port 8880 (#0)
* allocate connect buffer!
* Establish HTTP proxy tunnel to www.google.com:443
> CONNECT www.google.com:443 HTTP/1.1
> Host: www.google.com:443
> User-Agent: curl/7.79.1
> Proxy-Connection: Keep-Alive
>
* Recv failure: Connection reset by peer
* Received HTTP code 0 from proxy after CONNECT
* CONNECT phase completed!
* Closing connection 0
curl: (56) Recv failure: Connection reset by peer

nginx err "CONNECT www.google.com:443 HTTP/1.1" 499 0 "-" "curl/7.79.1"

  1. curl https://www.bing.com/ -v -x xxxxxx:8880 is success

  2. My proxy machine can access Google

  3. nginx conf:

server {        
    listen                         8880;
     resolver                       8.8.8.8 ipv6=off;
    # forward proxy for CONNECT requests
    proxy_connect;
    proxy_connect_allow            443 563;
    proxy_connect_connect_timeout  100s;
    proxy_connect_data_timeout     100s;

    # defined by yourself for non-CONNECT requests
    # Example: reverse proxy for non-CONNECT requests
    location / {
        proxy_pass http://$host;
        proxy_set_header Host $host;
    }

    access_log  access_log.log;
        error_log  error.log;

}
chobits commented 11 months ago

It appears that your TCP connection may have been blocked by the intermediate network operator.

You can extract the tcp packages in both client and server sides to examine the data flow using a tool like tcpdump.

My proxy machine can access Google

It seems that the problem occurs between the client and your proxy, not between your proxy and the elgoog server.

The first request from CONNECT tunnel (the CONNECT request) is not encrypted, as following:

guanzongjiang commented 11 months ago

It appears that your TCP connection may have been blocked by the intermediate network operator.

  • The client (curl) reported it received a RST tcp package.
  • The server (proxy_connect module on nginx) reported it received a FIN tcp package.

You can extract the tcp packages in both client and server sides to examine the data flow using a tool like tcpdump.

My proxy machine can access Google

It seems that the problem occurs between the client and your proxy, not between your proxy and the elgoog server.

The first request from CONNECT tunnel (the CONNECT request) is not encrypted, as following:

  • CONNECT request from curl
* Connected to xxxxxx (xxxxxx) port 8880 (#0)
* allocate connect buffer!
* Establish HTTP proxy tunnel to www.google.com:443
> CONNECT www.google.com:443 HTTP/1.1
> Host: www.google.com:443
> User-Agent: curl/7.79.1
> Proxy-Connection: Keep-Alive

my localhost ip: ip1 proxy ip: ip2

example1: curl https://www.bing.com/ -v -x ip2:8880 is success

tcpdump log: 15:25:56.653720 IP ip1.54454 > ip2.cddbp-alt: Flags [S], seq 1360722180, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 1786527561 ecr 0,sackOK,eol], length 0 15:25:56.770584 IP ip2.cddbp-alt > ip1.54454: Flags [S.], seq 3370598099, ack 1360722181, win 28960, options [mss 1460,sackOK,TS val 177209024 ecr 1786527561,nop,wscale 7], length 0 15:25:56.770653 IP ip1.54454 > ip2.cddbp-alt: Flags [.], ack 1, win 2058, options [nop,nop,TS val 1786527677 ecr 177209024], length 0 15:25:56.770882 IP ip1.54454 > ip2.cddbp-alt: Flags [P.], seq 1:117, ack 1, win 2058, options [nop,nop,TS val 1786527677 ecr 177209024], length 116 15:25:56.849881 IP ip2.cddbp-alt > ip1.54454: Flags [.], ack 117, win 227, options [nop,nop,TS val 177209137 ecr 1786527677], length 0 15:25:56.849888 IP ip2.cddbp-alt > ip1.54454: Flags [P.], seq 1:60, ack 117, win 227, options [nop,nop,TS val 177209146 ecr 1786527677], length 59 15:25:56.849931 IP ip1.54454 > ip2.cddbp-alt: Flags [.], ack 60, win 2057, options [nop,nop,TS val 1786527755 ecr 177209146], length 0 15:25:56.863681 IP ip1.54454 > ip2.cddbp-alt: Flags [P.], seq 117:348, ack 60, win 2057, options [nop,nop,TS val 1786527768 ecr 177209146], length 231 15:25:56.952799 IP ip2.cddbp-alt > ip1.54454: Flags [.], seq 1508:2956, ack 348, win 235, options [nop,nop,TS val 177209236 ecr 1786527768], length 1448

example2: curl https://www.google.com/ -v -x ip2:8880 is fail

tcpdump log: 15:24:07.440647 IP ip1.54135 > ip2.cddbp-alt: Flags [S], seq 2360919781, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 1786419044 ecr 0,sackOK,eol], length 0 15:24:07.553853 IP ip2.cddbp-alt > ip1.54135: Flags [S.], seq 2605493803, ack 2360919782, win 28960, options [mss 1460,sackOK,TS val 177099811 ecr 1786419044,nop,wscale 7], length 0 15:24:07.553931 IP ip1.54135 > ip2.cddbp-alt: Flags [.], ack 1, win 2058, options [nop,nop,TS val 1786419156 ecr 177099811], length 0 15:24:07.554118 IP ip1.54135 > ip2.cddbp-alt: Flags [P.], seq 1:121, ack 1, win 2058, options [nop,nop,TS val 1786419156 ecr 177099811], length 120 15:24:07.610284 IP ip2.cddbp-alt > ip1.54135: Flags [R.], seq 1, ack 121, win 3193, length 0 15:24:07.610290 IP ip2.cddbp-alt > ip1.54135: Flags [R.], seq 1, ack 121, win 3193, length 0 15:24:07.610291 IP ip2.cddbp-alt > ip1.54135: Flags [R.], seq 1, ack 121, win 3193, length 0 15:24:07.610292 IP ip2.cddbp-alt > ip1.54135: Flags [.], ack 121, win 227, options [nop,nop,TS val 177099922 ecr 1786419156], length 0 15:24:07.610350 IP ip1.54135 > ip2.cddbp-alt: Flags [R], seq 2360919902, win 0, length 0

I don't understand the difference between these two. If it's a problem with the client and proxy, why did the first example succeed And Example 2 was also successful on the proxy machine

chobits commented 11 months ago

I believe that addressing this issue lies beyond the technical scope of this project. It is likely that only the intermediate network operator or device can provide a solution.

~Additionally, if your proxy_connect server crashes, the Linux kernel will send a RST (reset) packet to your client.~

nibazshab commented 10 months ago

I also have this problem, and only of HTTPS Google. Because i try Github and others, all is right.

i try curl google.com -vx xxx:55580, all is right.

then i try curl https://google.com -vx xxx:55580, get error

* processing: https://google.com
*   Trying xxx.xxx.xxx.xxx:55580...
* Connected to xxx.link (xxx.xxx.xxx.xxx) port 55580
* CONNECT tunnel: HTTP/1.1 negotiated
* allocate connect buffer
* Establish HTTP proxy tunnel to google.com:443
> CONNECT google.com:443 HTTP/1.1
> Host: google.com:443
> User-Agent: curl/8.2.1
> Proxy-Connection: Keep-Alive
>
* Recv failure: 连接被对方重设
* Closing connection
curl: (56) Recv failure: 连接被对方重设
more information of HTTPS Github ``` * processing: https://github.com * Trying xxx.xxx.xxx.xxx:55580... * Connected to xxx.link (xxx.xxx.xxx.xxx) port 55580 * CONNECT tunnel: HTTP/1.1 negotiated * allocate connect buffer * Establish HTTP proxy tunnel to github.com:443 > CONNECT github.com:443 HTTP/1.1 > Host: github.com:443 > User-Agent: curl/8.2.1 > Proxy-Connection: Keep-Alive > < HTTP/1.1 200 Connection Established < Proxy-agent: nginx < * CONNECT phase completed * CONNECT tunnel established, response 200 * ALPN: offers h2,http/1.1 * TLSv1.3 (OUT), TLS handshake, Client hello (1): * CAfile: /etc/ssl/certs/ca-certificates.crt * CApath: none * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): * TLSv1.3 (IN), TLS handshake, Certificate (11): * TLSv1.3 (IN), TLS handshake, CERT verify (15): * TLSv1.3 (IN), TLS handshake, Finished (20): * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.3 (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256 * ALPN: server accepted h2 * Server certificate: * subject: C=US; ST=California; L=San Francisco; O=GitHub, Inc.; CN=github.com * start date: Feb 14 00:00:00 2023 GMT * expire date: Mar 14 23:59:59 2024 GMT * subjectAltName: host "github.com" matched cert's "github.com" * issuer: C=US; O=DigiCert Inc; CN=DigiCert TLS Hybrid ECC SHA384 2020 CA1 * SSL certificate verify ok. * using HTTP/2 * h2 [:method: GET] * h2 [:scheme: https] * h2 [:authority: github.com] * h2 [:path: /] * h2 [user-agent: curl/8.2.1] * h2 [accept: */*] * Using Stream ID: 1 > GET / HTTP/2 > Host: github.com > User-Agent: curl/8.2.1 > Accept: */* > * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * old SSL session ID is stale, removing < HTTP/2 200 < server: GitHub.com < date: Wed, 09 Aug 2023 09:12:27 GMT < content-type: text/html; charset=utf-8 < vary: X-PJAX, X-PJAX-Container, Turbo-Visit, Turbo-Frame, Accept-Language, Accept-Encoding, Accept , X-Requested-With < content-language: en-US < etag: W/"0a6e9e1ede5c6e7026bb28bffd29f2b8" < cache-control: max-age=0, private, must-revalidate < strict-transport-security: max-age=31536000; includeSubdomains; preload < x-frame-options: deny < x-content-type-options: nosniff < x-xss-protection: 0 < referrer-policy: origin-when-cross-origin, strict-origin-when-cross-origin ... < ... ```

this my nginx config file

...
 server {
     listen                         55580;
     resolver                       8.8.8.8;
     proxy_connect;
     proxy_connect_allow            443 80;
     proxy_connect_connect_timeout  10s;
     proxy_connect_read_timeout     10s;
     proxy_connect_send_timeout     10s;
     location / {
         proxy_pass http://$host;
         proxy_set_header Host $host;
     }
 }

this my nginx version

nginx version: nginx/1.24.0
built by clang 14.0.5 (https://github.com/llvm/llvm-project.git llvmorg-14.0.5-0-gc12386ae247c)
built with OpenSSL 1.1.1t-freebsd  7 Feb 2023
TLS SNI support enabled
configure arguments: --prefix=/usr/home/nginx --with-http_ssl_module --with-http_stub_s
tatus_module --with-http_realip_module --with-threads --add-module=ngx_http_proxy_connect_module
chobits commented 10 months ago

only two cases may produce RST error

  1. intermedia network problem
  2. nginx worker process with proxy_connect module crashed, then Operating System (like linux kernel) will send RST package directly to the connections held by original process
chobits commented 10 months ago

I also have this problem, and only of HTTPS Google. Because i try Github and others, all is right.

i try curl google.com -vx xxx:55580, all is right.

then i try curl https://google.com -vx xxx:55580, get error

* processing: https://google.com
*   Trying xxx.xxx.xxx.xxx:55580...
* Connected to xxx.link (xxx.xxx.xxx.xxx) port 55580
* CONNECT tunnel: HTTP/1.1 negotiated
* allocate connect buffer
* Establish HTTP proxy tunnel to google.com:443
> CONNECT google.com:443 HTTP/1.1
> Host: google.com:443
> User-Agent: curl/8.2.1
> Proxy-Connection: Keep-Alive
>
* Recv failure: 连接被对方重设
* Closing connection
curl: (56) Recv failure: 连接被对方重设

more information of HTTPS Github this my nginx config file

...
 server {
     listen                         55580;
     resolver                       8.8.8.8;
     proxy_connect;
     proxy_connect_allow            443 80;
     proxy_connect_connect_timeout  10s;
     proxy_connect_read_timeout     10s;
     proxy_connect_send_timeout     10s;
     location / {
         proxy_pass http://$host;
         proxy_set_header Host $host;
     }
 }

this my nginx version

nginx version: nginx/1.24.0
built by clang 14.0.5 (https://github.com/llvm/llvm-project.git llvmorg-14.0.5-0-gc12386ae247c)
built with OpenSSL 1.1.1t-freebsd  7 Feb 2023
TLS SNI support enabled
configure arguments: --prefix=/usr/home/nginx --with-http_ssl_module --with-http_stub_s
tatus_module --with-http_realip_module --with-threads --add-module=ngx_http_proxy_connect_module

As many people report the similar problem, I think I need to look into it again. Please help me debug with this problem, but I guess the main reason is that the package is blocked by intermedia network operator, like man-in-the-middle attack.

I need some more information from your case

  1. Did your nginx worker crash with the proxy_connect module enabled?
    • you can check log record in your nginx error.log, like this 2023/07/31 22:13:02 [alert] 3810#0: worker process 3811 exited on signal 11 or other alert level logs
    • or check your operating system log, like $ dmesg| grep segfault for linux
  2. Track the tcp packages flow on your server, to determine whether your nginx server or operating system sent the RST package actually
    • record the package on the machine of nginx server, not on your machine of the client. From the curl result, we already knew that RST package has been recevied by client.
    • using the command like $ sudo tcpdump -i any -nn port 55580 on the server side
chobits commented 10 months ago

If the main reason of this issue was caused by the intermedia network operator or other middle man, let me guess why it could be:

Although the proxied data flow over CONNECT tunnel could be encrypted, ussually https, the process of establishing the CONNECT tunnel is not encrypted (it can be encrypted if you need, see https CONNECT tunnel).

The middle man can then obtain two pieces of information from your request, and can do some blocking based on some strategies

  1. you want to use some proxying method to transfer network flow
    • which is different from curl -x ip:port http://xxx.com, this command just sends http request GET, not establishing the CONNECT tunnel.
  2. the destination(https://xxxx.com) you want to proxy
nibazshab commented 10 months ago

The server which run nginx is a public server, I can't use sudo, so i can't track the tcp packages flow on server

There is nothing in nginx/logs/error.log, it's blank. And nginx/logs/access.log is here

15x.1xx.1xx.x31 - - [11/Aug/2023:08:11:00 +0200] "CONNECT google.com:443 HTTP/1.1" 499 0 "-" "curl/8.
2.1"
15x.1xx.1xx.x31 - - [11/Aug/2023:08:11:42 +0200] "CONNECT twitter.com:443 HTTP/1.1" 200 3793 "-" "cur
l/8.2.1"

I don't change anything about nginx.conf - error_log. This is the case in nginx.conf

#error_log  logs/error.log;
#error_log  logs/error.log  notice;
#error_log  logs/error.log  info;
chobits commented 10 months ago

The server which run nginx is a public server, I can't use sudo, so i can't track the tcp packages flow on server

There is nothing in nginx/logs/error.log, it's blank. And nginx/logs/access.log is here

15x.1xx.1xx.x31 - - [11/Aug/2023:08:11:00 +0200] "CONNECT google.com:443 HTTP/1.1" 499 0 "-" "curl/8.
2.1"
15x.1xx.1xx.x31 - - [11/Aug/2023:08:11:42 +0200] "CONNECT twitter.com:443 HTTP/1.1" 200 3793 "-" "cur
l/8.2.1"

I don't change anything about nginx.conf - error_log. This is the case in nginx.conf

#error_log  logs/error.log;
#error_log  logs/error.log  notice;
#error_log  logs/error.log  info;

From this log 15x.1xx.1xx.x31 - - [11/Aug/2023:08:11:00 +0200] "CONNECT google.com:443 HTTP/1.1" 499 0 "-" "curl/8., the nginx server received a FIN package from the client side before nginx server will send 200 status code. (499 nginx status code means the client actively closes the connection.)

So I'm more sure the connection of the CONNECT request had been attacked by some middle man (maybe network operator, FW, server hosting provide and etc.), which sent a RST package to the client side and a FIN package to the server side.

iamkhalidbashir commented 10 months ago

I am having stange issue:- maybe @chobits can help me out

This is my config

server {
        listen                         3128;
        # dns resolver used by forward proxying
        resolver                       8.8.8.8 ipv6=off;

        # forward proxy for CONNECT requests
        proxy_connect;
        proxy_connect_allow            443 563;
        proxy_connect_connect_timeout  10s;

        # defined by yourself for non-CONNECT requests
        # Example: reverse proxy for non-CONNECT requests
        location / {
            proxy_pass http://$host;
            proxy_set_header Host $host;
        }
    }

And I get following response:-

curl  -x http://localhost:3128 -k https://google.com
<!DOCTYPE html>
<html lang=en>
  <meta charset=utf-8>
  <meta name=viewport content="initial-scale=1, minimum-scale=1, width=device-width">
  <title>Error 403 (Forbidden)!!1</title>
  <style>
    *{margin:0;padding:0}html,code{font:15px/22px arial,sans-serif}html{background:#fff;color:#222;padding:15px}body{margin:7% auto 0;max-width:390px;min-height:180px;padding:30px 0 15px}* > body{background:url(//www.google.com/images/errors/robot.png) 100% 5px no-repeat;padding-right:205px}p{margin:11px 0 22px;overflow:hidden}ins{color:#777;text-decoration:none}a img{border:0}@media screen and (max-width:772px){body{background:none;margin-top:0;max-width:none;padding-right:0}}#logo{background:url(//www.google.com/images/branding/googlelogo/1x/googlelogo_color_150x54dp.png) no-repeat;margin-left:-5px}@media only screen and (min-resolution:192dpi){#logo{background:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) no-repeat 0% 0%/100% 100%;-moz-border-image:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) 0}}@media only screen and (-webkit-min-device-pixel-ratio:2){#logo{background:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) no-repeat;-webkit-background-size:100% 100%}}#logo{display:inline-block;height:54px;width:150px}
  </style>
  <a href=//www.google.com/><span id=logo aria-label=Google></span></a>
  <p><b>403.</b> <ins>That’s an error.</ins>
  <p>Your client does not have permission to get URL <code>/</code> from this server.  <ins>That’s all we know.</ins>
chobits commented 10 months ago

hi @iamkhalidbashir

It seems that it worked, from the curl result, that means CONNECT tunnel was established and got a 403 response from proxied server. If you ask me why it is 403 while not 200 status code, I could not help you, it bases on your network environment. You can directly check google.com via curl https://google.com, the result should be 403 same as curl->proxy_connect->backend situcation if your proxy_connect is on your local machine.

I am having stange issue:- maybe @chobits can help me out

This is my config

server {
        listen                         3128;
        # dns resolver used by forward proxying
        resolver                       8.8.8.8 ipv6=off;

        # forward proxy for CONNECT requests
        proxy_connect;
        proxy_connect_allow            443 563;
        proxy_connect_connect_timeout  10s;

        # defined by yourself for non-CONNECT requests
        # Example: reverse proxy for non-CONNECT requests
        location / {
            proxy_pass http://$host;
            proxy_set_header Host $host;
        }
    }

And I get following response:-

curl  -x http://localhost:3128 -k https://google.com
<!DOCTYPE html>
<html lang=en>
  <meta charset=utf-8>
  <meta name=viewport content="initial-scale=1, minimum-scale=1, width=device-width">
  <title>Error 403 (Forbidden)!!1</title>
  <style>
    *{margin:0;padding:0}html,code{font:15px/22px arial,sans-serif}html{background:#fff;color:#222;padding:15px}body{margin:7% auto 0;max-width:390px;min-height:180px;padding:30px 0 15px}* > body{background:url(//www.google.com/images/errors/robot.png) 100% 5px no-repeat;padding-right:205px}p{margin:11px 0 22px;overflow:hidden}ins{color:#777;text-decoration:none}a img{border:0}@media screen and (max-width:772px){body{background:none;margin-top:0;max-width:none;padding-right:0}}#logo{background:url(//www.google.com/images/branding/googlelogo/1x/googlelogo_color_150x54dp.png) no-repeat;margin-left:-5px}@media only screen and (min-resolution:192dpi){#logo{background:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) no-repeat 0% 0%/100% 100%;-moz-border-image:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) 0}}@media only screen and (-webkit-min-device-pixel-ratio:2){#logo{background:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) no-repeat;-webkit-background-size:100% 100%}}#logo{display:inline-block;height:54px;width:150px}
  </style>
  <a href=//www.google.com/><span id=logo aria-label=Google></span></a>
  <p><b>403.</b> <ins>That’s an error.</ins>
  <p>Your client does not have permission to get URL <code>/</code> from this server.  <ins>That’s all we know.</ins>

It seems that it worked, from the curl result, that means CONNECT tunnel was established and got a 403 response from proxied server. If you ask me why it is 403 while not 200 status code, I could not help you, it bases on your network environment. You can directly check google.com via curl https://google.com, the result should be 403 same as curl->proxy_connect->backend situcation if your proxy_connect is on your local machine.

iamkhalidbashir commented 10 months ago

It seems that it worked, from the curl result, that means CONNECT tunnel was established and got a 403 response from proxied server. If you ask me why it is 403 while not 200 status code, I could not help you, it bases on your network environment. You can directly check google.com via curl https://google.com, the result should be 403 same as curl->proxy_connect->backend situcation if your proxy_connect is on your local machine.

I am having stange issue:- maybe @chobits can help me out This is my config

server {
        listen                         3128;
        # dns resolver used by forward proxying
        resolver                       8.8.8.8 ipv6=off;

        # forward proxy for CONNECT requests
        proxy_connect;
        proxy_connect_allow            443 563;
        proxy_connect_connect_timeout  10s;

        # defined by yourself for non-CONNECT requests
        # Example: reverse proxy for non-CONNECT requests
        location / {
            proxy_pass http://$host;
            proxy_set_header Host $host;
        }
    }

And I get following response:-

curl  -x http://localhost:3128 -k https://google.com
<!DOCTYPE html>
<html lang=en>
  <meta charset=utf-8>
  <meta name=viewport content="initial-scale=1, minimum-scale=1, width=device-width">
  <title>Error 403 (Forbidden)!!1</title>
  <style>
    *{margin:0;padding:0}html,code{font:15px/22px arial,sans-serif}html{background:#fff;color:#222;padding:15px}body{margin:7% auto 0;max-width:390px;min-height:180px;padding:30px 0 15px}* > body{background:url(//www.google.com/images/errors/robot.png) 100% 5px no-repeat;padding-right:205px}p{margin:11px 0 22px;overflow:hidden}ins{color:#777;text-decoration:none}a img{border:0}@media screen and (max-width:772px){body{background:none;margin-top:0;max-width:none;padding-right:0}}#logo{background:url(//www.google.com/images/branding/googlelogo/1x/googlelogo_color_150x54dp.png) no-repeat;margin-left:-5px}@media only screen and (min-resolution:192dpi){#logo{background:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) no-repeat 0% 0%/100% 100%;-moz-border-image:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) 0}}@media only screen and (-webkit-min-device-pixel-ratio:2){#logo{background:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) no-repeat;-webkit-background-size:100% 100%}}#logo{display:inline-block;height:54px;width:150px}
  </style>
  <a href=//www.google.com/><span id=logo aria-label=Google></span></a>
  <p><b>403.</b> <ins>That’s an error.</ins>
  <p>Your client does not have permission to get URL <code>/</code> from this server.  <ins>That’s all we know.</ins>

It seems that it worked, from the curl result, that means CONNECT tunnel was established and got a 403 response from proxied server. If you ask me why it is 403 while not 200 status code, I could not help you, it bases on your network environment. You can directly check google.com via curl https://google.com, the result should be 403 same as curl->proxy_connect->backend situcation if your proxy_connect is on your local machine.

Actually the issue is still with the module, because a simple curl request on the same system returns 200 but proxied through module returns 403

this just happens for google, dont know what is google doing to detect if the request is proxied

iamkhalidbashir commented 10 months ago

Its an hetzner cloud server which has ipv4 and ipv6 Could that be a problem ?

chobits commented 10 months ago

Its an hetzner cloud server which has ipv4 and ipv6 Could that be a problem ?

If you use command curl, it will use IP address from /etc/resolv.conf as DNS server, while the proxy_connect module uses your configured directive resolver 8.8.8.8 as DNS server.

You can configure the proxy_connect module directive resolver <IP> to IP address from /etc/resolv.conf

iamkhalidbashir commented 10 months ago

I just tried, 127.0.0.11 in /etc/resolv.conf Using it instead of 8.8.8.8 ipv6=off; Still gives same error

proxied (upstream ip) is now same as curl (direct) google server ip

Still getting 403 for google through proxy but not with curl on same system

Been struggling to solve this for 2 days now ;(

chobits commented 10 months ago

I just tried, 127.0.0.11 in /etc/resolv.conf Using it instead of 8.8.8.8 ipv6=off; Still gives same error

proxied (upstream ip) is now same as curl (direct) google server ip

Still getting 403 for google through proxy but not with curl on same system

Been struggling to solve this for 2 days now ;(

add -sv option to your curl command, and show two results from curl -sv https://google.com and curl -sv -x http://localhost:3128 -k https://google.com

lloydzhou commented 9 months ago

i have same problem, got error log:

proxy_connect: client prematurely closed connection (104: Connection reset by peer), client: xxx.xxx.xxx.xx, server: , request: "CONNECT www.google.com:443 HTTP/1.1", host: "www.google.com:443"

"CONNECT www.google.com:443 HTTP/1.1" 499 0 "-" "curl/8.2.1"

but when i run curl on another server(IP in USA and IP in Japan), success get html.

chobits commented 9 months ago

If there is like a middle man attack, this module might not address the problem. 😢

chobits commented 9 months ago

For the other users, I just have been investigating the problem following this thread. But I havent been able to find a soloution yet now if the reason is a middle man attack.

lanistor commented 3 months ago

If you are in china, this is disabled to proxy to google, this is aliyun's reply.

截屏2024-03-18 15 55 04
chobits commented 3 months ago

If someone believes the issue is not related to a network problem and has discovered some meaningful issues (such as potential software anomalies). Please feel free to file a new issue and include your thoughts, particularly the steps to reproduce. I have closed and locked this one for it's too heated.