Basically i use nordvpn, it came with a meshnet feature, which is now being discontinued. I tried other tunnel options but they weren’t as reliable and the speeds weren’t great (maybe my ISP sucks?). I took my self-hosted setup public, and in an attempt to gate the api paths with authentication, in nginx i set up a check, which refuses requests if they do not contain a specific header (do advice me if there are better auth methods and if this is dumb).
Now it works great in local network, cuz doesn’t require authentication. When accessing remotely, it would appear some requests are sent with the headers, while others aren’t (honestly, i am not sure, but looks like it). Commenting out the header check in nginx fixes the issue, so yeah, i believe the requests are failing the check. Nginx logs show some requests with code 200, and the rest get dropped off (444).
I cannot upload the debug log as is from the app, as it contains sensitive information (which is another issue in its own right). I am still clicking on the checkmark for the sake of making this request.
I don’t mind sending you the edited logs though. I am sending them to you via email.
I can’t debug your network, you need to tell me where and what is supposedly not sending the headers and the proxy logs part.
The logs only shows error 502 and so some proxy / server side configuration error.
502 is error by cloudflare. nginx gives 444, so cloudflare shows 502. i am replying to same mail for info on nginx logs.
EDIT: as explained in mail, it’s the /rest/stream.view path. you can here see in the ss that it otherwise works perfectly when attempted on curl with correct headers, and results in the file k.mp3 which mpv detects and plays well (tags are visible), which is to say it shouldn’t give 444 (as logged by nginx) if accessed properly
would it be easier if i gave you headers in mail for you to work with?
then i’ll just change those later till you fix the issue
you have the rest for access from logs
EDIT: i uploaded the logs via app. it include headers. sorry for the roundabout way. should have done that i guess
Let’s be clear: The app does send the headers as the feature is used by a lot of people.
So no seing that your proxy returns an error would not help, you need to debug your proxy configuration and actually be sure of why it returns 444 and you’ll probably see that’s it’s something else.
Properly log things on your proxy to actually know what you receive, check what Cloudflare changes in the middle too then show me exactly what is the issue.
each log line ends with the header i use for authentication. it appears to be duplicated. i should also look at if it’s just sending the same header twice and my implementation is crap which is causing the issue, which otherwise shouldn’t happen
it was some proxy quirk. my bad, my implementation was the culprit after all. i only tried other methods for debugging like curl, and other access methods.
sorry for the annoyance, most importantly, thanks for the time
EDIT: nginx debug confirmed the request from symfonium was correct
