Login returns 502 error (v0.13.1)

[gitmotion]

After updating to v0.13.1 login seems to break/return 502 error and wont work until i clear cookies. but sign in is currently impossible for me. it may have something to do with my setup in general but just thought I'd post something here about it in case anyone else was facing the same issue

Setup:

• Docker
• Cloudflare
• NPM (reverse proxy)
• Authentik

Side note: would be nice if we could set up multiple origin urls so that we can view from local domains/ip's for the same instance if this isn't already possible

Thanks in advance!

[TheBig-O]

Same problems here.
Can't login and get errors.

[Flomp]

Hey,
thanks for the report. 502 Bad Gateway is not an error returned by wanderer but by the proxy in front of it when the app that it's pointing to is down.
Could you please provide error logs from the wanderer-web and wanderer-db containers? Are there any client side errors in the browser console?
Also, some minimal steps to reproduce would be great. So far I was not able to.

[logburn]

Same issue here. Strangely both the logs (of all containers) and browser console show no related errors, and coming to the site from incognito shows the home screen with no issues.
For completion, the error in the console that I'm seeing is related to the favicon: GET https://trails.logburn.com/favicon.ico 502 (Bad Gateway)
And the error I get from wanderer-web container is related to i18n: [svelte-i18n] Message "trail" has syntax error: Incorrect locale information provided

It might be worth noting that I am seeing the cookie pb_auth set, which to me indicates that everything is fine up until it actually tries to do something when logged in:

{"token":"ey...1ns","model":{"avatar":"","bio":"","collectionId":"_pb_users_auth_","collectionName":"users","created":"2025-01-13 21:48:35.252Z","email":"[email protected]","emailVisibility":false,"id":"rrr...ktk","token":"ey...kq4","updated":"2025-01-13 21:48:35.263Z","username":"logburn","verified":false}}

Steps to produce:

Set up new server per the provided compose
Create a user with username, email, and password
The page seems to "get stuck" and doesn't leave the signup page (though it scrolls to the top)
Attempt to manually refresh the page, 502 is returned instead

I also just tried logging in with incorrect password (again, using incognito gives access until login) and the validation returns as invalid, successfully and with no 502 error. Seems to be directly related to a successful login, whether it's from signup or actual login.

[logburn]

Sorry to keep commenting on this but I can't help but keep digging :)

I have a very similar setup to @gitmotion so I decided to dig there. Cloudflare didn't seem to be the issue (bypassing the "orange cloud" did nothing), but accessing directly from IP did fix the issue. So it seems to be something about NPM. I'll probably keep digging to find a solution and I'll edit this comment if I find anything.

EDIT
Fixed! I looked at the nginx logs and found this to be the error:
upstream sent too big header while reading response header from upstream, client: [ip], server: trails.logburn.com, request: "GET / HTTP/2.0", upstream: "http://[ip]:3000/", host: "trails.logburn.com"
and decided to just try letting bigger headers. So in NPM's advanced config for this subdomain, I put this in the box (notice this is not in a server{}, just this plain text):

    # Increase buffer size for headers
    proxy_buffer_size 16k;
    proxy_buffers 4 32k;
    proxy_busy_buffers_size 64k;

@gitmotion Can you try this and see if it also works for you?

TL;DR
Seems like headers are too large for Nginx Proxy Manager to handle by default, and the above config needs to be set in order to increase the allowed header size.

[gitmotion]

@logburn that's awesome no need to be sorry! i haven't had the time to look deeper so thanks for looking into that, i'll give that a try and let you know how it goes!

[gitmotion]

@logburn nice just gave it a try and that worked for me!

i guess that does make me wonder if there's any way to reduce the size of data passed through the headers so wanderer can work in more flexible scenarios (but i suspect it's due to cloudflare, npm, & authentik in between), but in either case this workaround seems to be fine for my setup and server specs.

p.s. really feeling the performance improvements of wanderer from the recent updates, looking good @Flomp 👍🏻

(will close this issue in about a week in case someone else runs into a similar issue)

[Flomp]

@logburn that's some great detective work! Thank you! I investigated a bit which change in v0.13.1 might have caused this issue. I had already found the problem that caused newly registered users to not be redirected properly. This was caused by a change I made to the nav bar component:
a2d5d5d#diff-2dbd897d205b111c11b1d8b4e09d82774479af37587e4ce02cc3a833ee48c5c2
This causes the navbar to already render correctly on the server if there is a logged-in user (no flash of the Login button before loading the page client-side). However this caused the aforementioned problem. I fixed it on the main branch (24c89ba) but have not released the next patch.
If you could test (I plan on publishing the patch at the end of the week) if that also solves the header size issue that would be great!

[logburn]

@Flomp I want to run on the same environment to make sure it solves the issue (especially since I believe the NPM reverse proxy to be the source) but I'm rather inexperienced with Dockerfile. I'm getting errors when I try to build and I don't know how to resolve them. If you build it I can try pulling and running it!
Or if you'd rather help me build it locally I'm stuck on this: ERROR: failed to solve: failed to compute cache key: failed to calculate checksum of ref c8c7...d77d::0brj...yrs3: "/build": not found
from line 3 of the web Dockerfile ( 3 | >>> COPY ./build build/)

[Flomp]

I just released v0.13.2 which includes the aforementioned fix. So no need to build it yourself.
@logburn: In case you would still like to set up a dev environment, please follow the steps described in the documentation:

https://wanderer.to/getting-started/local-development/#building

[logburn]

I'm still getting the same 502 error with the new build, and the same fix works for me.

[TheBig-O]

I just updated to the latest release and still get a 502 error. The last working version for me was 12.

[Flomp]

Thanks for reporting back. I investigated a bit more about what could cause the large header size, and I think the only plausible cause is the pb_auth cookie. It contains the auth token and profile info. Currently, it also contains the user's bio, which I will definitely change as it balloons the cookie/header size. With an empty bio my response headers are ~1.3kB. That should be lower than any default limit of nginx.
Can you see a similar value in your requests?

[logburn]

Mine's actually smaller than that, about 1.1kB. I was also getting the error with no bio set (in fact I had just made the account so nothing was set at all, other than defaults). But I agree that separating out variables from the auth cookie is a good idea, and probably will fix the issue.

[Flomp]

With v0.14.0 the bio is migrated out of the auth cookie. I'll close this as the original issue has been resolved by the fix proposed by @logburn.

[fsmeets84]

I have encountered the exact same issue with my installation in Docker on my Synology.
However, the fix mentioned in ##156 (comment) doesn't work for me.
Or to be more precise, I'm not able to change the proxy_buffer_size, proxy_buffers and proxy_busy_buffers_size at all.

When using the default Reverse Proxy option on a Synology NAS there is no option to change the headers.

[Flomp]

I found the culprit:
sveltejs/kit#6790

Deleting the link attribute from the response headers reduces the size from 4.9kB to ~1.5kB. So this should fix it. I did not notice any increased latency while testing. So I think it should be fine to just leave it out.
I'll include it in the next patch

[gitmotion]

@Flomp nice find 🚀