HTTPS Behind a Load Balancer
HTTPS Behind a Load Balancer
Overview
The Tracker stack is served behind HTTPS in AWS, with the load balancer terminating TLS before forwarding traffic to the frontend containers. The same headers and proxy rules also matter in local nginx-based development when you want to mirror production routing.
Use this guide when you need to keep browser traffic, frontend proxying, and API redirects aligned with HTTPS.
Required Behavior
At the edge:
- Port 80 should redirect to 443.
- The load balancer should forward the original scheme with
X-Forwarded-Proto: https. - The frontend should generate HTTPS links and API requests.
At the proxy layer:
- Preserve the incoming
Hostheader. - Forward
X-Forwarded-ForandX-Forwarded-Proto. - If nginx proxies to an HTTPS upstream, enable SNI with
proxy_ssl_server_name on;. - Avoid returning
http://URLs in redirects or generated links.
Recommended nginx pattern
location /api/ {
proxy_pass http://dev:8000/api/;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
}
If nginx connects to an upstream over HTTPS instead of plain HTTP, add:
proxy_ssl_server_name on;
proxy_ssl_protocols TLSv1.2 TLSv1.3;
Common Symptoms
- Browser console mixed-content warnings.
- Redirects from
https://tohttp://. - API requests that work locally but fail once they are routed through the AWS frontend.
- 307 redirect loops caused by inconsistent trailing-slash handling.
If the issue is a trailing slash or redirect mismatch, see API URL Handling.
AWS Notes
The authoritative AWS infrastructure details live in:
This page documents the HTTPS/proxy contract, not the full deployment topology.
Testing
- Confirm that requests arrive with
X-Forwarded-Proto: https. - Confirm the browser only sees
https://URLs. - Check nginx and frontend logs for redirects that downgrade to HTTP.
- Verify the AWS frontend can reach the API without mixed-content errors.