downstream 502 with authentik, but all other services are working fine.

[StefanSa]

Hi there,
First of all, thank you for this helpful tool.
I have published a few services with pangolin and haven't encountered any problems.
However, with authentik, i get a downstream 502 error after a few clicks on the login window.

{"ClientAddr":"213.xxx.xxx.xxx:59702","ClientHost":"213.xxx.xxx.xxx","DownstreamContentSize":11,"DownstreamStatus":502,"Duration":103274559,"RequestMethod":"GET","RequestPath":"/ws/client/","RequestProtocol":"HTTP/1.1","RetryAttempts":0,"ServiceName":"8-service@http","StartUTC":"2025-08-14T09:23:50.850451708Z","TLSCipher":"TLS_AES_128_GCM_SHA256","TLSVersion":"1.3","downstream_Content-Type":"","level":"info","msg":"","origin_Content-Type":"","request_Cookie":"REDACTED","request_User-Agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/139.0.0.0 Safari/537.36 Edg/139.0.0.0","request_X-Forwarded-Proto":"wss","request_X-Real-Ip":"213.xxx.xxx.xxx","time":"2025-08-14T09:23:50Z"}

Interestingly, i don't have any problems with authentik when it runs on the same host (VPS) as pangolin, i.e., the local site.
Authentik is generally accessible on the home network and works without any problems.
Does anyone understand why pangolin (traefik) has such problems with authentik through the tunnel?
The authentic log file does not contain any information regarding this issue.

Thanks for any help.

[StefanSa]

Shouldn't that be X-Forwarded-Proto: wss X-Forwarded-Proto: https instead?
According to the Authentik documentation, X-Forwarded-Proto should signal the HTTPS/HTTP scheme (i.e., usually https, not wss).

GET /ws/client/ HTTP/1.1
Host: authentik-new.xxxx.org
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/139.0.0.0 Safari/537.36 Edg/139.0.0.0
Accept-Encoding: gzip, deflate, br, zstd
Accept-Language: de,de-DE;q=0.9,en;q=0.8,en-GB;q=0.7,en-US;q=0.6
Cache-Control: no-cache
Connection: Upgrade
Cookie: p_session_token_s.1755157721921=tz4bqu224yax6r6p46dbsnvtnkwjflub; authentik_session=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzaWQiOiJ4OTF3Njc3b2hkZm9udWY5NXNhdG12N3l4aHFvdTNqOSIsImlzcyI6ImF1dGhlbnRpayIsInN1YiI6ImFub255bW91cyIsImF1dGhlbnRpY2F0ZWQiOmZhbHNlLCJhY3IiOiJnb2F1dGhlbnRpay5pby9jb3JlL2RlZmF1bHQifQ.rBeAeB2Kia2bOoPgQhzgWuH2wklK0scSJlBJCHUXuB8
Origin: https://authentik-new.xxx.org
Pragma: no-cache
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
Sec-WebSocket-Key: P0ySiZ0CX0re5Sd3K1wPOQ==
Sec-WebSocket-Version: 13
Upgrade: websocket
X-Forwarded-For: 213.xxx.xxx.xxx
X-Forwarded-Host: authentik-new.xxxxxx.org
X-Forwarded-Port: 443
X-Forwarded-Proto: wss
X-Forwarded-Server: c2a3697aa2fd
X-Real-Ip: 213.xxx.xxx.xxx

[oschwartz10612]

Shouldn't that be |X-Forwarded-Proto: wss| |X-Forwarded-Proto: https| instead?

502 is bad gateway which usually indicates Pangolin cant reach the target application but you show the headers. How are you getting the headers? Is that just a test? I would check to make sure that Newt can see Authentik. If you are in docker there are some gotchas like localhost is inside of the container etc... What does your deployment look like?

[StefanSa]

@oschwartz10612
Hi Owen,
with the help of Astral on Discord, i have already tried pretty much everything to solve this problem.
https://discord.com/channels/1325658630518865980/1405545552762110033

To me, it currently looks like traefik is not sending all the headers that are needed.
https://docs.goauthentik.io/docs/install-config/reverse-proxy

To understand where the problem might be, i installed fpr Proxy on the VPS and Ubuntu Server (Home).
On the VPS, i installed nginx in front, which terminates tls here, and there are no problems here.
There is indeed a problem with the current configuration in Pangolin regarding ws(s).

[HearthCore]

I run Authentik in my homelab via docker. Pangolin is on a remote VPS.
There's a newt on a different docker host that routes to it via IPv4.
I've had to adjust nothing, just added authentik and everything works as intended.

I do however have my authentik instance set to no authentication in pangolin, not that it matters in this case.

[oschwartz10612]

Hum yeah I know we and others have got it running behind Pangolin. I still feel like the 502s are because newt cant reach Authentik for some reason. In the newt logs (maybe turn on debug) do you see it creating the proxy to autnentik at the right place and do you see any log messages about failures to write to it? We could also do some TCPDUMPing to see if packets are making it to authentik.

[StefanSa]

@oschwartz10612

That's not entirely correct.
Authentication is already accessible; i can enter my username and password in the login screen, but then i get a 502 error, probably because a WebSocket connection is being established here.
So i don't get the 502 error message right away.

[0rn0lf]

I'm pretty sure i have the same issue.
Backstory: Before I implemented Pangolin I used dyndns to access my services directly via traefik.
I switched to fiber and wasnt able to get an IPv4 adress from my provider. Thats why I switched to Pangolin.
I use adguard for internal DNS resolution so i use the same domain for internal and external access.

Currently I only have Authentik in place for audiobookshelf and tandoor. Both worked well before but with Pangolin I always receive a 502 bad gateway error after authentication in Authentik.
Before I added Authentik in Pangolin, the authentication page wasnt loading. After adding Authentik to Pangolin and the authentication page was loading and i was able to login. But as soon as youre redirected to the original service e.g. Audiobookshelf, you receive an authorization error and the log shows error 502 bad gateway.

I thought it would be related to DNS issues because the containers resolve my external IP instead of the internal traefik ip even though, the dns seems to be configured correctly in the container

[HearthCore]

Standard question: did your clear your browser cache?

…

________________________________ Von: 0rn0lf ***@***.***> Gesendet: Monday, August 18, 2025 4:37:48 PM An: fosrl/pangolin ***@***.***> Cc: TimoYi | HearthCore | ZenWise ***@***.***>; Comment ***@***.***> Betreff: Re: [fosrl/pangolin] downstream 502 with authentik, but all other services are working fine. (Issue #1279) [https://avatars.githubusercontent.com/u/35098710?s=20&v=4]0rn0lf left a comment (fosrl/pangolin#1279)<#1279 (comment)> I'm pretty sure i have the same issue. Backstory: Before I implemented Pangolin I used dyndns to access my services directly via traefik. I switched to fiber and wasnt able to get an IPv4 adress from my provider. Thats why I switched to Pangolin. I use adguard for internal DNS resolution so i use the same domain for internal and external access. Currently I only have Authentik in place for audiobookshelf and tandoor. Both worked well before but with Pangolin I always receive a 502 bad gateway error after authentication in Authentik. Before I added Authentik in Pangolin, the authentication page wasnt loading. After adding Authentik to Pangolin and the authentication page was loading and i was able to login. But as soon as youre redirected to the original service e.g. Audiobookshelf, you receive an authorization error and the log shows error 502 bad gateway. image.png (view on web)<https://github.com/user-attachments/assets/883f867e-33c0-40f4-bb12-fb6d6a7fb1af> I thought it would be related to DNS issues because the containers resolve my external IP instead of the internal traefik ip even though, the dns seems to be configured correctly in the container — Reply to this email directly, view it on GitHub<#1279 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AANPNVMEGSQ33U7R5GQZCBD3OHQLZAVCNFSM6AAAAACD4H567KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTCOJXGIYDMMZWHA>. You are receiving this because you commented.Message ID: ***@***.***>

[StefanSa]

Hi there,
There is a positive update.
In authentik, i changed the value authentik_host of the authentik Embedded Outpost from IP-address:port to https:\\authentik.mydom.com.

Apparently, during the initial installation, the IP was entered here instead of the FQDN, which probably caused the problems with establishing the WebSocket connection.

Thank you for your support.
The ticket can be closed