Record the public hostname, proxy chain and redirect sequence. Confirm whether the application listener is reachable outside the trusted proxy path.

1. Check the allowed host configuration for the intended environment and application version. Permit the necessary hostnames without broadly accepting arbitrary hosts.

2. Review HTTPS enforcement in Rails and the proxy. Confirm the app receives reliable information about the original HTTPS connection.

3. Configure trusted proxy and forwarded-header behavior according to the actual topology. Ensure client-supplied values cannot override the trusted scheme or host.

4. Check cookie domain and secure settings after hostname changes. Test an authenticated request from a new browser session.

5. Restart the app with the corrected configuration and remove temporary diagnostic endpoints.

Follow the public HTTP-to-HTTPS redirect and confirm it ends at the canonical page. Verify HTTPS requests do not redirect repeatedly and unexpected hosts remain rejected.

Several independent force-HTTPS rules can create a loop when one layer sees every request as HTTP. Correct the scheme information before adding another redirect.

Suppose you move a Rails website from a temporary hostname to app.example.com. The home page now reports a blocked host, while another URL repeatedly switches between HTTP and HTTPS. Treat these as separate observations, not evidence that every security setting needs disabling.

1. Record the exact public URL and the hostname named in the Rails log. A health-check hostname may differ from the customer-facing hostname.
2. Check the production host allowlist. Add the specific legitimate name through your deployment configuration, then restart using your normal release process.
3. Trace the redirect chain with browser developer tools. Record which response creates each Location header and whether the proxy forwards the original scheme.
4. Test sign-in and sign-out after the redirect stops. A working public home page does not prove secure session cookies use the intended domain and scheme.

Do not add a rule that trusts every incoming forwarded header. A header should be trusted because the connection comes through an approved proxy, not merely because the header exists. When you contact our support team, include the redirect sequence, time of the test and relevant log excerpt. Remove cookies, session identifiers and access tokens first. Tell us which proxy or CDN sits in front of the application so we can investigate the correct layer.

• Preparing Rails encrypted credentials for production
• Running Express behind a trusted reverse proxy
• Troubleshooting browser CORS errors for an API
• Building and serving Rails production assets
• Use command and configuration examples from our knowledgebase safely

• Rails configuration
• Rails security