github-starred/pangolin
2
0
Fork 0
mirror of https://github.com/fosrl/pangolin.git synced 2026-05-08 21:59:09 -05:00
Code Issues 564 Packages Projects Releases 72 Wiki Activity

[GH-ISSUE #1034] Access to websocket server not possible. #10491

New Issue
Closed
opened 2026-05-06 13:52:41 -05:00 by GiteaMirror · 27 comments
GiteaMirror commented 2026-05-06 13:52:41 -05:00
Owner
Copy Link

Originally created by @EmbeddedAndMore on GitHub (Jul 8, 2025).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/1034

i am trying to access a webserver on mylocal setup through Pangolin proxy, the HTTP part loads without problem but then i get the following error:

Image

If the URL for the server is: https://foo.proxy.domain.com, the URL that i not loading is wss://foo.proxy.domain.com.

How can i fix it?

Also, i am using v1.6.2 of Pangolin

Sincerely

Originally created by @EmbeddedAndMore on GitHub (Jul 8, 2025). Original GitHub issue: https://github.com/fosrl/pangolin/issues/1034 i am trying to access a webserver on mylocal setup through Pangolin proxy, the HTTP part loads without problem but then i get the following error: <img width="1913" height="207" alt="Image" src="https://github.com/user-attachments/assets/8e1444b4-5567-4596-b7ff-3f3efa59d473" /> If the URL for the server is: `https://foo.proxy.domain.com`, the URL that i not loading is `wss://foo.proxy.domain.com`. How can i fix it? Also, i am using v1.6.2 of Pangolin Sincerely
GiteaMirror added the stale label 2026-05-06 13:52:41 -05:00
GiteaMirror commented 2026-05-06 13:52:46 -05:00
Author
Owner
Copy Link

@oschwartz10612 commented on GitHub (Jul 8, 2025):

Hum this is strange. I am not 100% sure how to trouble shoot here. If HTTPS is working fine with no complaints from the browser about a self signed cert then the websocket should work as well. Do you see any logs in your target application that indicate if the websocket is making it to the server or not? I would like to get an idea if it is getting terminated by pangolin or by the target web server.

Only other thing I could think of is that the websocket is not getting sent with the cookies necessary for passing the pangolin auth. Could you check by disabling the auth on the resource and see if the websocket connects? If so it is getting blocked.

<!-- gh-comment-id:3049368000 --> @oschwartz10612 commented on GitHub (Jul 8, 2025): Hum this is strange. I am not 100% sure how to trouble shoot here. If HTTPS is working fine with no complaints from the browser about a self signed cert then the websocket should work as well. Do you see any logs in your target application that indicate if the websocket is making it to the server or not? I would like to get an idea if it is getting terminated by pangolin or by the target web server. Only other thing I could think of is that the websocket is not getting sent with the cookies necessary for passing the pangolin auth. Could you check by disabling the auth on the resource and see if the websocket connects? If so it is getting blocked.
GiteaMirror commented 2026-05-06 13:52:46 -05:00
Author
Owner
Copy Link

@eeveezayas commented on GitHub (Jul 8, 2025):

not to hijack @EmbeddedAndMore 's issue but I have a similar one where using openwebui with pangolin auth it has a websockets issue resulting in SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data, which doesn't occur if I disable auth in pangolin.

<!-- gh-comment-id:3049707934 --> @eeveezayas commented on GitHub (Jul 8, 2025): not to hijack @EmbeddedAndMore 's issue but I have a similar one where using openwebui with pangolin auth it has a websockets issue resulting in `SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data`, which doesn't occur if I disable auth in pangolin.
GiteaMirror commented 2026-05-06 13:52:48 -05:00
Author
Owner
Copy Link

@EmbeddedAndMore commented on GitHub (Jul 9, 2025):

@oschwartz10612 I am trying to troubleshoot and give you more info, and I found something even weirder. When I run the Newt on the target machine, after the first try from the tunneled connection, I get the same error even when I want to access the web server locally.

So when the Newt is running, i get the error both locally and through tunnel. As soon as i terminate Newt, everything seems normal again.

Unfortunately, the WebServer is a third-party software which i don't have the knowledge or capability to dig into for troubleshooting.

Also disabling the Auth didn't help.

<!-- gh-comment-id:3051277029 --> @EmbeddedAndMore commented on GitHub (Jul 9, 2025): @oschwartz10612 I am trying to troubleshoot and give you more info, and I found something even weirder. When I run the Newt on the target machine, after the first try from the tunneled connection, I get the same error even when I want to access the web server locally. So when the Newt is running, i get the error both **locally** and through **tunnel**. As soon as i terminate Newt, everything seems normal again. Unfortunately, the WebServer is a third-party software which i don't have the knowledge or capability to dig into for troubleshooting. Also disabling the Auth didn't help.
GiteaMirror commented 2026-05-06 13:52:50 -05:00
Author
Owner
Copy Link

@oschwartz10612 commented on GitHub (Jul 9, 2025):

Okay. For @eeveezayas, I think that sounds like an "auth issue." Meaning the client application does not use the cookies provided when connecting to the websocket and, therefore, gets rejected by Badger when it gets to the proxy. I have seen this before, and unfortunately, it is kind of an issue with the client application—we can't do anything to auth traffic if it does not respect standards and pass some sort of identifier, I think—but please, anyone, correct me. Your best option might be to either disable auth on this resource or look into the dev tools in your browser and see what the WSS path is (like /ws or something) and whitelist that path in your auth. It is not 100% secure but might get you close to what you need.

For @EmbeddedAndMore, this is stranger. It sounds like maybe not something with the auth but with the client application. I do empathize with trying to use some provided vendor software and having no visibility! If you can get any logs, it could be helpful to troubleshoot. I would also try to stop Newt, turn off auth in Pangolin, and try to connect again and see if it works. Off the top of my head, it might not like the connection from Newt and "dies" as soon as it gets the error in the first place? Maybe you could look into the documentation to see if there is any need to add a trust proxy field to trust the Newt connection or the Traefik connection? Or maybe you can reach out to the support of the target application and ask them if there is any config needed when running behind an authenticated reverse proxy?

<!-- gh-comment-id:3053338394 --> @oschwartz10612 commented on GitHub (Jul 9, 2025): Okay. For @eeveezayas, I think that sounds like an "auth issue." Meaning the client application does not use the cookies provided when connecting to the websocket and, therefore, gets rejected by Badger when it gets to the proxy. I have seen this before, and unfortunately, it is kind of an issue with the client application—we can't do anything to auth traffic if it does not respect standards and pass some sort of identifier, I think—but please, anyone, correct me. Your best option might be to either disable auth on this resource or look into the dev tools in your browser and see what the WSS path is (like /ws or something) and whitelist that path in your auth. It is not 100% secure but might get you close to what you need. For @EmbeddedAndMore, this is stranger. It sounds like maybe not something with the auth but with the client application. I do empathize with trying to use some provided vendor software and having no visibility! If you can get any logs, it could be helpful to troubleshoot. I would also try to stop Newt, turn off auth in Pangolin, and try to connect again and see if it works. Off the top of my head, it might not like the connection from Newt and "dies" as soon as it gets the error in the first place? Maybe you could look into the documentation to see if there is any need to add a trust proxy field to trust the Newt connection or the Traefik connection? Or maybe you can reach out to the support of the target application and ask them if there is any config needed when running behind an authenticated reverse proxy?
GiteaMirror commented 2026-05-06 13:52:50 -05:00
Author
Owner
Copy Link

@EmbeddedAndMore commented on GitHub (Jul 10, 2025):

@oschwartz10612 Today i tested the CF tunnel and it worked without problem.

i am 100% sure that the WebSocket client is not the newest and best.

I'll try to check the other things you mentioned.

<!-- gh-comment-id:3057309169 --> @EmbeddedAndMore commented on GitHub (Jul 10, 2025): @oschwartz10612 Today i tested the CF tunnel and it worked without problem. i am 100% sure that the WebSocket client is not the newest and best. I'll try to check the other things you mentioned.
GiteaMirror commented 2026-05-06 13:52:52 -05:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jul 25, 2025):

This issue has been automatically marked as stale due to 14 days of inactivity. It will be closed in 14 days if no further activity occurs.

<!-- gh-comment-id:3115405299 --> @github-actions[bot] commented on GitHub (Jul 25, 2025): This issue has been automatically marked as stale due to 14 days of inactivity. It will be closed in 14 days if no further activity occurs.
GiteaMirror commented 2026-05-06 13:52:54 -05:00
Author
Owner
Copy Link

@JulScsl commented on GitHub (Jul 26, 2025):

I also experience similar issues. @EmbeddedAndMore can you elaborate your thoughts on the websocket client and how you came to this conclusion?

<!-- gh-comment-id:3121553476 --> @JulScsl commented on GitHub (Jul 26, 2025): I also experience similar issues. @EmbeddedAndMore can you elaborate your thoughts on the websocket client and how you came to this conclusion?
GiteaMirror commented 2026-05-06 13:52:57 -05:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Aug 11, 2025):

This issue has been automatically marked as stale due to 14 days of inactivity. It will be closed in 14 days if no further activity occurs.

<!-- gh-comment-id:3173004603 --> @github-actions[bot] commented on GitHub (Aug 11, 2025): This issue has been automatically marked as stale due to 14 days of inactivity. It will be closed in 14 days if no further activity occurs.
GiteaMirror commented 2026-05-06 13:52:59 -05:00
Author
Owner
Copy Link

@Momi-V commented on GitHub (Aug 15, 2025):

I have a similar issue with Cockpit. This can easily be reproduced by just trying to forward https://cockpit.domain to https://localhost:9090 on any linux server with cockpit and newt installed and running.

This is even the case without ANY auth enabled.

It looks like wss://domain just isn't accepted at all (it's either http:// or https://) and therefore the connection just fails.

<!-- gh-comment-id:3191236150 --> @Momi-V commented on GitHub (Aug 15, 2025): I have a similar issue with Cockpit. This can easily be reproduced by just trying to forward https://cockpit.domain to https://localhost:9090 on any linux server with cockpit and newt installed and running. This is even the case without ANY auth enabled. It looks like wss://domain just isn't accepted at all (it's either http:// or https://) and therefore the connection just fails.
GiteaMirror commented 2026-05-06 13:53:00 -05:00
Author
Owner
Copy Link

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

@HPPinata do you see anything in the console logs / network tab that
could help?

In the network tab is it sending the cookie in the wss request? If not
that is why auth is blocking it.

What you could do as a tmp fix is to add a rule to bypass auth on the
websocket. I am aware though that is not secure - but if the client
application does not send the cookie we are a but SOL...

<!-- gh-comment-id:3193441162 --> @oschwartz10612 commented on GitHub (Aug 16, 2025): @HPPinata do you see anything in the console logs / network tab that could help? In the network tab is it sending the cookie in the wss request? If not that is why auth is blocking it. What you could do as a tmp fix is to add a rule to bypass auth on the websocket. I am aware though that is not secure - but if the client application does not send the cookie we are a but SOL...
GiteaMirror commented 2026-05-06 13:53:01 -05:00
Author
Owner
Copy Link

@Momi-V commented on GitHub (Aug 16, 2025):

@oschwartz10612 there isn't any auth enabled in pangolin.

It's just an exposed test server. The only auth is the native one in Cockpit (and it works locally). I'll send some network tab logs over soon, but the only error I see is: wss://cockpit.domain connection refused.

The site loads over http(s), I input the server password and then the web socket fails to connect and I get served an error page.

As far as I can tell, there's nothing pangolin side I could configure, because pangolin shouldn't block any connections.

It's just used for it's forwarding and https, not it's auth capabilities.

<!-- gh-comment-id:3193462014 --> @Momi-V commented on GitHub (Aug 16, 2025): @oschwartz10612 there isn't *any* auth enabled in pangolin. It's just an exposed test server. The only auth is the native one in Cockpit (and it works locally). I'll send some network tab logs over soon, but the only error I see is: wss://cockpit.domain connection refused. The site loads over http(s), I input the server password and then the web socket fails to connect and I get served an error page. As far as I can tell, there's nothing pangolin side I could configure, because pangolin shouldn't block *any* connections. It's just used for it's forwarding and https, not it's auth capabilities.
GiteaMirror commented 2026-05-06 13:53:02 -05:00
Author
Owner
Copy Link

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

Oh very interesting then. Yeah everything should just pass through
Traefik at that point! If you watch in the network tab of your browser
and look for the websocket do you get an error code in the response? 502
or 404, 403, etc...?

<!-- gh-comment-id:3193462994 --> @oschwartz10612 commented on GitHub (Aug 16, 2025): Oh very interesting then. Yeah everything should just pass through Traefik at that point! If you watch in the network tab of your browser and look for the websocket do you get an error code in the response? 502 or 404, 403, etc...?
GiteaMirror commented 2026-05-06 13:53:03 -05:00
Author
Owner
Copy Link

@Momi-V commented on GitHub (Aug 16, 2025):

I just found out what was wrong on my end... Layer 8 (kind of).

The corporate firewall I was behind when originally diagnosing this yesterday apparently really doesn't like web sockets.
From a privately controlled network and client Cockpit works both with and without auth.

For documentations sake: The browser console just spits out NS_ERROR_NET_RESET since it's blocked before ever reaching Pangolin.

<!-- gh-comment-id:3193470458 --> @Momi-V commented on GitHub (Aug 16, 2025): I just found out what was wrong on my end... Layer 8 (kind of). The corporate firewall I was behind when originally diagnosing this yesterday apparently really doesn't like web sockets. From a privately controlled network and client Cockpit works both with and without auth. For documentations sake: The browser console just spits out NS_ERROR_NET_RESET since it's blocked before ever reaching Pangolin.
GiteaMirror commented 2026-05-06 13:53:03 -05:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Aug 31, 2025):

This issue has been automatically marked as stale due to 14 days of inactivity. It will be closed in 14 days if no further activity occurs.

<!-- gh-comment-id:3239629624 --> @github-actions[bot] commented on GitHub (Aug 31, 2025): This issue has been automatically marked as stale due to 14 days of inactivity. It will be closed in 14 days if no further activity occurs.
GiteaMirror commented 2026-05-06 13:53:04 -05:00
Author
Owner
Copy Link

@krod1408 commented on GitHub (Sep 6, 2025):

For me pangolin has been running fine and now I can not reach any of the resource sites

<!-- gh-comment-id:3260188283 --> @krod1408 commented on GitHub (Sep 6, 2025): For me pangolin has been running fine and now I can not reach any of the resource sites
GiteaMirror commented 2026-05-06 13:53:05 -05:00
Author
Owner
Copy Link

@krod1408 commented on GitHub (Sep 6, 2025):

I just did not feel like dealing with it I believe the error was newt connection refused...Docker socket availability for Newt r2wp08w2ry4rs1f: available=false, socketPath=

2025-09-06T01:36:37.410Z [warn]: Newt r2wp08w2ry4rs1f does not have Docker socket access. but like i said it has been running fine till now.

<!-- gh-comment-id:3260190013 --> @krod1408 commented on GitHub (Sep 6, 2025): I just did not feel like dealing with it I believe the error was newt connection refused...Docker socket availability for Newt r2wp08w2ry4rs1f: available=false, socketPath= 2025-09-06T01:36:37.410Z [warn]: Newt r2wp08w2ry4rs1f does not have Docker socket access. but like i said it has been running fine till now.
GiteaMirror commented 2026-05-06 13:53:09 -05:00
Author
Owner
Copy Link

@oschwartz10612 commented on GitHub (Sep 6, 2025):

@krod1408 is the issue that newt cant connect to Pangolin or that the
docker socket does not work? If you updated newt please make sure to use
the latest version - there was a patch allowing tcp and unix access to
the docker socket that introduced a bug that could be causing this. I
fixed it in the latest release.

<!-- gh-comment-id:3262948526 --> @oschwartz10612 commented on GitHub (Sep 6, 2025): @krod1408 is the issue that newt cant connect to Pangolin or that the docker socket does not work? If you updated newt please make sure to use the latest version - there was a patch allowing tcp and unix access to the docker socket that introduced a bug that could be causing this. I fixed it in the latest release.
GiteaMirror commented 2026-05-06 13:53:10 -05:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Sep 21, 2025):

This issue has been automatically marked as stale due to 14 days of inactivity. It will be closed in 14 days if no further activity occurs.

<!-- gh-comment-id:3315392312 --> @github-actions[bot] commented on GitHub (Sep 21, 2025): This issue has been automatically marked as stale due to 14 days of inactivity. It will be closed in 14 days if no further activity occurs.
GiteaMirror commented 2026-05-06 13:53:12 -05:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Oct 5, 2025):

This issue has been automatically closed due to inactivity. If you believe this is still relevant, please open a new issue with up-to-date information.

<!-- gh-comment-id:3368628948 --> @github-actions[bot] commented on GitHub (Oct 5, 2025): This issue has been automatically closed due to inactivity. If you believe this is still relevant, please open a new issue with up-to-date information.
GiteaMirror commented 2026-05-06 13:53:13 -05:00
Author
Owner
Copy Link

@okfro commented on GitHub (Dec 7, 2025):

I receive the same error when using a resource with a target configuration using newt. I have a wireguard tunnel between my instances, so I can use different targets for the same resource to test.

  1. https://ex.amp.le: Newt -> Docker -> container_name:port. Normal https browsing works (very slow, fwiw), but websocket calls fail with 500 error--fail to connect to websocket.
  2. https://ex.amp.ple: Local -> ip:port (connecting cross continents with wireguard). Normal https browsing is very fast and no websocket errors.

fwiw, the service I am using is Komodo--I am testing the latest 2.0-swarm branch which uses websockets in the latest periphery agent.

<!-- gh-comment-id:3622611732 --> @okfro commented on GitHub (Dec 7, 2025): I receive the same error when using a resource with a target configuration using newt. I have a wireguard tunnel between my instances, so I can use different targets for the same resource to test. 1. https://ex.amp.le: Newt -> Docker -> container_name:port. Normal https browsing works (very slow, fwiw), but websocket calls fail with 500 error--fail to connect to websocket. 2. https://ex.amp.ple: Local -> ip:port (connecting cross continents with wireguard). Normal https browsing is very fast and no websocket errors. fwiw, the service I am using is Komodo--I am testing the latest 2.0-swarm branch which uses websockets in the latest periphery agent.
GiteaMirror commented 2026-05-06 13:53:15 -05:00
Author
Owner
Copy Link

@nefariouslegion commented on GitHub (Dec 19, 2025):

I receive the same error when using a resource with a target configuration using newt. I have a wireguard tunnel between my instances, so I can use different targets for the same resource to test.

  1. https://ex.amp.le: Newt -> Docker -> container_name:port. Normal https browsing works (very slow, fwiw), but websocket calls fail with 500 error--fail to connect to websocket.
  2. https://ex.amp.ple: Local -> ip:port (connecting cross continents with wireguard). Normal https browsing is very fast and no websocket errors.

fwiw, the service I am using is Komodo--I am testing the latest 2.0-swarm branch which uses websockets in the latest periphery agent.

Hi,

I'm running into a websocket issue while trying to get ownCloud setup and with Collabora. Wondering if you ever figured out a solution because I am also using Komodo

<!-- gh-comment-id:3673265990 --> @nefariouslegion commented on GitHub (Dec 19, 2025): > I receive the same error when using a resource with a target configuration using newt. I have a wireguard tunnel between my instances, so I can use different targets for the same resource to test. > > 1. https://ex.amp.le: Newt -> Docker -> container_name:port. Normal https browsing works (very slow, fwiw), but websocket calls fail with 500 error--fail to connect to websocket. > 2. https://ex.amp.ple: Local -> ip:port (connecting cross continents with wireguard). Normal https browsing is very fast and no websocket errors. > > fwiw, the service I am using is Komodo--I am testing the latest 2.0-swarm branch which uses websockets in the latest periphery agent. Hi, I'm running into a websocket issue while trying to get ownCloud setup and with Collabora. Wondering if you ever figured out a solution because I am also using Komodo
GiteaMirror commented 2026-05-06 13:53:18 -05:00
Author
Owner
Copy Link

@okfro commented on GitHub (Dec 19, 2025):

Hi,

I'm running into a websocket issue while trying to get ownCloud setup and with Collabora. Wondering if you ever figured out a solution because I am also using Komodo

For the time being, I am just avoiding Newt altogether--it's orders of magnitude slower than my wireguard mesh connection. I started adding Newt sites because manually expanding wireguard mesh configs is tedious and I thought Newt would be an easy workaround.

<!-- gh-comment-id:3676603450 --> @okfro commented on GitHub (Dec 19, 2025): > > Hi, > > I'm running into a websocket issue while trying to get ownCloud setup and with Collabora. Wondering if you ever figured out a solution because I am also using Komodo For the time being, I am just avoiding Newt altogether--it's orders of magnitude slower than my wireguard mesh connection. I started adding Newt sites because manually expanding wireguard mesh configs is tedious and I thought Newt would be an easy workaround.
GiteaMirror commented 2026-05-06 13:53:22 -05:00
Author
Owner
Copy Link

@kylepyke commented on GitHub (Dec 29, 2025):

I receive the same error when using a resource with a target configuration using newt. I have a wireguard tunnel between my instances, so I can use different targets for the same resource to test.

  1. https://ex.amp.le: Newt -> Docker -> container_name:port. Normal https browsing works (very slow, fwiw), but websocket calls fail with 500 error--fail to connect to websocket.
  2. https://ex.amp.ple: Local -> ip:port (connecting cross continents with wireguard). Normal https browsing is very fast and no websocket errors.

fwiw, the service I am using is Komodo--I am testing the latest 2.0-swarm branch which uses websockets in the latest periphery agent.

Hi,

I'm running into a websocket issue while trying to get ownCloud setup and with Collabora. Wondering if you ever figured out a solution because I am also using Komodo

Hilariously, I'm having this exact same issue, with this exact same setup minus Komodo. Did you find anything?

<!-- gh-comment-id:3695928499 --> @kylepyke commented on GitHub (Dec 29, 2025): > > I receive the same error when using a resource with a target configuration using newt. I have a wireguard tunnel between my instances, so I can use different targets for the same resource to test. > > > > 1. https://ex.amp.le: Newt -> Docker -> container_name:port. Normal https browsing works (very slow, fwiw), but websocket calls fail with 500 error--fail to connect to websocket. > > 2. https://ex.amp.ple: Local -> ip:port (connecting cross continents with wireguard). Normal https browsing is very fast and no websocket errors. > > > > fwiw, the service I am using is Komodo--I am testing the latest 2.0-swarm branch which uses websockets in the latest periphery agent. > > Hi, > > I'm running into a websocket issue while trying to get ownCloud setup and with Collabora. Wondering if you ever figured out a solution because I am also using Komodo Hilariously, I'm having this exact same issue, with this exact same setup minus Komodo. Did you find anything?
GiteaMirror commented 2026-05-06 13:53:26 -05:00
Author
Owner
Copy Link

@pblue3 commented on GitHub (Jan 10, 2026):

I have the same problem with ttyd: the websocket is constantly closed after a few seconds.

<!-- gh-comment-id:3733432371 --> @pblue3 commented on GitHub (Jan 10, 2026): I have the same problem with ttyd: the websocket is constantly closed after a few seconds.
GiteaMirror commented 2026-05-06 13:53:28 -05:00
Author
Owner
Copy Link

@kylepyke commented on GitHub (Jan 14, 2026):

I receive the same error when using a resource with a target configuration using newt. I have a wireguard tunnel between my instances, so I can use different targets for the same resource to test.

  1. https://ex.amp.le: Newt -> Docker -> container_name:port. Normal https browsing works (very slow, fwiw), but websocket calls fail with 500 error--fail to connect to websocket.
  2. https://ex.amp.ple: Local -> ip:port (connecting cross continents with wireguard). Normal https browsing is very fast and no websocket errors.

fwiw, the service I am using is Komodo--I am testing the latest 2.0-swarm branch which uses websockets in the latest periphery agent.

Hi,

I'm running into a websocket issue while trying to get ownCloud setup and with Collabora. Wondering if you ever figured out a solution because I am also using Komodo

FYI, I figured this out from this post here:

https://github.com/fosrl/pangolin/issues/2176#issuecomment-3695380702

You have to add:

      encodedCharacters:
        allowEncodedSlash: true
        allowEncodedQuestionMark: true

Under entryPoints: websecure: http: portion of your traefik config.

<!-- gh-comment-id:3747749353 --> @kylepyke commented on GitHub (Jan 14, 2026): > > I receive the same error when using a resource with a target configuration using newt. I have a wireguard tunnel between my instances, so I can use different targets for the same resource to test. > > > > 1. https://ex.amp.le: Newt -> Docker -> container_name:port. Normal https browsing works (very slow, fwiw), but websocket calls fail with 500 error--fail to connect to websocket. > > 2. https://ex.amp.ple: Local -> ip:port (connecting cross continents with wireguard). Normal https browsing is very fast and no websocket errors. > > > > fwiw, the service I am using is Komodo--I am testing the latest 2.0-swarm branch which uses websockets in the latest periphery agent. > > Hi, > > I'm running into a websocket issue while trying to get ownCloud setup and with Collabora. Wondering if you ever figured out a solution because I am also using Komodo FYI, I figured this out from this post here: https://github.com/fosrl/pangolin/issues/2176#issuecomment-3695380702 You have to add: ``` encodedCharacters: allowEncodedSlash: true allowEncodedQuestionMark: true ``` Under `entryPoints: websecure: http:` portion of your traefik config.
GiteaMirror commented 2026-05-06 13:53:29 -05:00
Author
Owner
Copy Link

@okfro commented on GitHub (Jan 18, 2026):

FYI, I figured this out from this post here:

#2176 (comment)

You have to add:

      encodedCharacters:
        allowEncodedSlash: true
        allowEncodedQuestionMark: true

Under entryPoints: websecure: http: portion of your traefik config.

I will test this afternoon and report back its effect on my setup. I have been working with Gerbil disabled since the issue first appeared for me, so I will have to shuffle some pieces around (i.e. could take a Mississippi minute to properly test).

<!-- gh-comment-id:3765401968 --> @okfro commented on GitHub (Jan 18, 2026): > FYI, I figured this out from this post here: > > [#2176 (comment)](https://github.com/fosrl/pangolin/issues/2176#issuecomment-3695380702) > > You have to add: > > ``` > encodedCharacters: > allowEncodedSlash: true > allowEncodedQuestionMark: true > ``` > > Under `entryPoints: websecure: http:` portion of your traefik config. I will test this afternoon and report back its effect on my setup. I have been working with Gerbil disabled since the issue first appeared for me, so I will have to shuffle some pieces around (i.e. could take a Mississippi minute to properly test).
GiteaMirror commented 2026-05-06 13:53:30 -05:00
Author
Owner
Copy Link

@kylepyke commented on GitHub (Jan 19, 2026):

No worries. It's been working for me 😀

<!-- gh-comment-id:3766503015 --> @kylepyke commented on GitHub (Jan 19, 2026): No worries. It's been working for me 😀
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
api
authentication
bug
config
dependencies
docker
documentation
enhancement
good first issue
help wanted
Improvement
Look Into
needs investigating
networking
new feature
non-critical bug
potential bug
pull-request
Mirrored from GitHub Pull Request
 question
reverse proxy
Security
stale
ui
wontfix
No Label stale
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/pangolin#10491
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?