URLs longer than 76* characters never make it to their destination #580

New Issue

2025-11-13T12:04:58-06:00

GiteaMirror commented

2025-11-13 12:04:58 -06:00

Originally created by @lhjt on GitHub (Aug 12, 2025).

Thanks so much for this amazing project.

Bug Description

I am trying to make requests to my tunneled service:

newt forwarding to localhost:7777, and is successfully forwarding most requests
I have a services listening on https://abcdef.tld

Trying to make requests to URLs longer than 76 characters just never make it to their destination (the listener on the remote machine never receives a connection from newt)

Example of a path could be http://abcdef.tld/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.

I was unable to find the exact number (76 happened to be for this domain). If I make a new site with a subdomain that is shorter, then the length limit for the whole URL increases before it stops proxying requests.

Steps to Reproduce

Set up HTTP listener, have a service it's meant to forward to
Set up a site that points to that listener
Try make a request with say a path >100 chars.
Observe that no requests are making it to the endpoint on the remote machine. Continue removing chars and making requests until it finally works.

Expected Behavior

The request should make it through like all other requests.

Actual Behavior

Nothing is tunneled. I can see a log in traefik indicating it is attempting to send the data, but nothing happens. No errors in newt either.

Environment

Pangolin Version: 1.8.0
OS: Ubuntu 24 LTS - MacOS 15.6 for clients

Error Messages

N/A

Additional Context

Functional and non-functional requests have the same traefik log:

2025-08-12T17:46:54Z DBG fmt/print.go:305 > Badger: Valid session module=github.com/fosrl/badger plugin=plugin-badger runtime=
2025-08-12T17:46:54Z DBG github.com/traefik/traefik/v3/pkg/server/service/loadbalancer/wrr/wrr.go:207 > Service selected by WRR: 8ad00bcbee50905d

...

2025-08-12T17:47:00Z DBG fmt/print.go:305 > Badger: Valid session module=github.com/fosrl/badger plugin=plugin-badger runtime=
2025-08-12T17:47:00Z DBG github.com/traefik/traefik/v3/pkg/server/service/loadbalancer/wrr/wrr.go:207 > Service selected by WRR: 8ad00bcbee50905d

Happy to provide more data if needed.

Originally created by @lhjt on GitHub (Aug 12, 2025). Thanks so much for this amazing project. ## Bug Description I am trying to make requests to my tunneled service: - newt forwarding to `localhost:7777`, and is successfully forwarding most requests - I have a services listening on `https://abcdef.tld` Trying to make requests to URLs longer than 76 characters just never make it to their destination (the listener on the remote machine never receives a connection from newt) Example of a path could be `http://abcdef.tld/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa`. I was unable to find the exact number (76 happened to be for this domain). If I make a new site with a subdomain that is shorter, then the length limit for the **whole** URL increases before it stops proxying requests. ## Steps to Reproduce 1. Set up HTTP listener, have a service it's meant to forward to 2. Set up a site that points to that listener 3. Try make a request with say a path >100 chars. 4. Observe that no requests are making it to the endpoint on the remote machine. Continue removing chars and making requests until it finally works. ## Expected Behavior The request should make it through like all other requests. ## Actual Behavior Nothing is tunneled. I can see a log in traefik indicating it is attempting to send the data, but nothing happens. No errors in newt either. ## Environment - **Pangolin Version**: `1.8.0` - **OS**: Ubuntu 24 LTS - MacOS 15.6 for clients ## Error Messages N/A ## Additional Context Functional and non-functional requests have the same traefik log: ``` 2025-08-12T17:46:54Z DBG fmt/print.go:305 > Badger: Valid session module=github.com/fosrl/badger plugin=plugin-badger runtime= 2025-08-12T17:46:54Z DBG github.com/traefik/traefik/v3/pkg/server/service/loadbalancer/wrr/wrr.go:207 > Service selected by WRR: 8ad00bcbee50905d ... 2025-08-12T17:47:00Z DBG fmt/print.go:305 > Badger: Valid session module=github.com/fosrl/badger plugin=plugin-badger runtime= 2025-08-12T17:47:00Z DBG github.com/traefik/traefik/v3/pkg/server/service/loadbalancer/wrr/wrr.go:207 > Service selected by WRR: 8ad00bcbee50905d ``` Happy to provide more data if needed.

GiteaMirror added the needs investigating reverse proxy bug labels 2025-11-13 12:04:58 -06:00

GiteaMirror commented

2025-11-13 12:04:59 -06:00

@lhjt commented on GitHub (Aug 13, 2025):

Had a look at some more logs and enabled debug logs on pangolin itself. The request seems to be getting through it okay:

2025-08-13T05:39:24.928Z [debug]: Verify session: Badger sent { ... }
2025-08-13T05:39:24.929Z [debug]: Request IP: {"requestIp":"..."}
2025-08-13T05:39:24.929Z [debug]: Client IP: {"clientIp":"..."}
2025-08-13T05:39:24.932Z [debug]: Resource allowed because no auth

For clarity, when I make the request with curl and -vvv it gets up to the following and just waits forever:

> GET /aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa HTTP/2
> Host: abcdef.tld
> User-Agent: curl/8.7.1
> Accept: */*
>
* Request completely sent off
*

@lhjt commented on GitHub (Aug 13, 2025): Had a look at some more logs and enabled debug logs on pangolin itself. The request seems to be getting through it okay: ``` 2025-08-13T05:39:24.928Z [debug]: Verify session: Badger sent { ... } 2025-08-13T05:39:24.929Z [debug]: Request IP: {"requestIp":"..."} 2025-08-13T05:39:24.929Z [debug]: Client IP: {"clientIp":"..."} 2025-08-13T05:39:24.932Z [debug]: Resource allowed because no auth ``` For clarity, when I make the request with curl and `-vvv` it gets up to the following and just waits forever: ``` > GET /aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa HTTP/2 > Host: abcdef.tld > User-Agent: curl/8.7.1 > Accept: */* > * Request completely sent off * ```

GiteaMirror commented

2025-11-13 12:04:59 -06:00

@oschwartz10612 commented on GitHub (Aug 16, 2025):

Hum this is very strange. I would be shocked if no urls over this length were working because many people would be complaining that their app does not work. So I wonder if this has to do for some reason with the initial auth url or something else. Once its authed does it allow you to curl with more chars?

Anything unique about your setup you can think of before I try to reproduce?

@oschwartz10612 commented on GitHub (Aug 16, 2025): Hum this is very strange. I would be _shocked_ if no urls over this length were working because many people would be complaining that their app does not work. So I wonder if this has to do for some reason with the initial auth url or something else. Once its authed does it allow you to curl with more chars? Anything unique about your setup you can think of before I try to reproduce?

GiteaMirror commented

2025-11-13 12:04:59 -06:00

@lhjt commented on GitHub (Aug 16, 2025):

Thanks for having a look at this @oschwartz10612 - my setup shouldn't be too unusual, bar authentication. I am also surprised that nobody else has run into this issue (meaning it could very well be something on my end)

For this scenario I actually have auth fully disabled, so I shouldn't be getting redirected to any auth urls.
I also have https disabled (I have an istio ingress gateway in front of the http part of pangolin that does TLS termination). I can confirm that this ingress gateway functions completely fine and is able to support URLs longer than 76 chars!

Please let me know if there are any other details you'd like me to provide 🙂

@lhjt commented on GitHub (Aug 16, 2025): Thanks for having a look at this @oschwartz10612 - my setup shouldn't be too unusual, bar authentication. I am also surprised that nobody else has run into this issue (meaning it could very well be something on my end) - For this scenario I actually have auth fully disabled, so I shouldn't be getting redirected to any auth urls. - I also have https disabled (I have an istio ingress gateway in front of the http part of pangolin that does TLS termination). I can confirm that this ingress gateway functions completely fine and is able to support URLs longer than 76 chars! Please let me know if there are any other details you'd like me to provide 🙂

GiteaMirror commented

2025-11-13 12:04:59 -06:00

@oschwartz10612 commented on GitHub (Aug 23, 2025):

Hey sorry for the delay!

I am not super familiar with istio ingress gateway but I wonder if this
is interacting with Pangolin in a way thats causing the failure when the
URL is long. Is it just a proxy in front of Pangolin?

Maybe it could be helpful to do a request from Istio not to Pangolin but
to a whoami instance and paste the result? I wonder if there are some
things it is doing the request.

Could also be some sort of packet sizing problem but I would not think
that would be it.

@oschwartz10612 commented on GitHub (Aug 23, 2025): Hey sorry for the delay! I am not super familiar with istio ingress gateway but I wonder if this is interacting with Pangolin in a way thats causing the failure when the URL is long. Is it just a proxy in front of Pangolin? Maybe it could be helpful to do a request from Istio not to Pangolin but to a whoami instance and paste the result? I wonder if there are some things it is doing the request. Could also be some sort of packet sizing problem but I would not think that would be it.