I am using a global proxy as described in Run an NGINX proxy on Fly · Fly. My origin server is hosted on Heroku
I am intermittently seeing a 302 redirect to http://[my domain]:8080/security/login. The requests causing 302 redirects are not hitting my origin server at all. (1. there are no entries in the heroku router logs 2. the via ‘1.1 vegur’ header is missing)
Any idea why this is happening? What am I missing here?
Would you mind trying an image like this? GitHub - fly-apps/edge-nginx: A fly app nginx config
The one you’re using probably won’t send access logs to stdout.
Our own proxy will never send a 302 on its own.
Sometimes app frameworks don’t log when they return a 302. This looks like nginx set a header to [my domain]:8080 and that’s what your app on heroku used to redirect.
Thanks for your inputs jermone. I’ll try the image and let you know.
Regarding the headers, I thought so too. but the string :8080/security/login does not occur in any of our source code, not nginx, not heroku, not the database. So I am kind of lost here.
Also, does the service thycotic hold any significance to fly.io?
We don’t have any hardcoded paths like that and I’ve never heard of thycotic before.
It could be bots scanning your domain after adding new certs looking for vulnerabilities. They monitor cert transparency logs from LetsEncrypt and start scanning for paths like wp-login.php or /admin/login right after certs are issued for ~30m. You can ignore them. The 302 could be an http to https redirect.
More info on bot scanning Bot scan (not from letsencrypt) immediately after cert issue - Site Feedback - Let's Encrypt Community Support
We don’t have any hardcoded paths like that and I’ve never heard of thycotic before.
That’s odd. We did not either, but that service is throwing a lot of unrelated 404 errors.
Regarding Bot Scanning, yes there are some unrelated logs entries in fly logs. Those are unlrated to the issue we are facing
It doesn’t have to be this exact string. How about security/login? Is that were people are redirected when they need to login?
Your upstream is set to your-app.herokuapp.com, and your nginx listener is set to :8080. It’s possible nginx is setting the Host (or X-Forwarded-Host) header to [my domain]:8080 and your web app is using it to generate the Location header for 302 redirects.
Yes, I checked that as well. security/login also does not occur in our code as well. If a user is unauthorized, we redirect them to /client_contacts/sign_in or /users/sign_in