Mixed content behind a proxy: why your app builds http:// links, and the fix per framework.

The visitor’s browser connects to the proxy over HTTPS. The proxy decrypts the request and forwards it to your app on a local port, over HTTP. From the app’s side, nothing says the original request was secure. A framework that builds absolute URLs from the incoming request (asset helpers, url() and redirect() calls, OAuth callback URLs, sitemap links) writes http://.

Proxies pass the original details in headers. Your framework ignores them until you tell it which proxy to believe, because any client can send an X-Forwarded-Proto header of its own.

Browsers split http:// resources on an HTTPS page into two groups:

• A redirect loop (ERR_TOO_MANY_REDIRECTS) is the same bug from the other side: the app forces HTTPS, sees HTTP on every request and redirects again.
• Logins that don’t stick: a session cookie marked secure is never set when the framework believes the connection is HTTP.
• Every visitor has the same IP, the proxy’s, in your logs and rate limits. That’s X-Forwarded-For being ignored.

On Canner, Caddy terminates HTTPS and forwards to your app on 127.0.0.1. These are the headers your app receives. Caddy ignores X-Forwarded-* values sent by clients, so the values are its own:

Trust the proxy’s address, not everyone. On Canner that address is loopback, because your app listens on 127.0.0.1. The last column says what Canner’s default start command already handles.

// Express
app.set("trust proxy", "loopback");

# Django (settings.py)
SECURE_PROXY_SSL_HEADER = ("HTTP_X_FORWARDED_PROTO", "https")

# Flask
from werkzeug.middleware.proxy_fix import ProxyFix
app.wsgi_app = ProxyFix(app.wsgi_app, x_for=1, x_proto=1, x_host=1)

# Rails (config/environments/production.rb, Rails 8 default)
config.assume_ssl = true
config.force_ssl = true

// Laravel (bootstrap/app.php)
->withMiddleware(function (Middleware $middleware): void {
    $middleware->trustProxies(at: '127.0.0.1');
})

# Spring Boot (application.properties)
server.forward-headers-strategy=native

Settings like trust proxy: true, trustProxies(at: '*') or --forwarded-allow-ips='*' believe any X-Forwarded-* header from anyone who can reach the app. Express’s own docs warn that a client can then supply any value unless the last proxy overwrites the headers. On a platform where your app only accepts connections on loopback, trusting loopback is the exact setting.

Content-Security-Policy: upgrade-insecure-requests makes the browser rewrite http:// subresources to https://, including blocked ones. It hides the symptom on the page, but redirects, cookies, emails and API responses still carry the wrong scheme. Fix the framework setting first.

Add a temporary route that prints the scheme, host and client IP as your framework sees them, deploy, open it over HTTPS, then delete it. The Express version is below; every framework has an equivalent (request.is_secure() in Django, request.ssl? in Rails, $request->secure() in Laravel). Set the values your app needs with the CLI (canner env set) or the dashboard, and check the app’s output in the logs.

// A throwaway route: what does the app think the request was?
app.get("/_debug/proto", (req, res) => {
  res.json({
    protocol: req.protocol,        // want "https"
    secure: req.secure,            // want true
    host: req.hostname,            // want your public hostname
    ip: req.ip,                    // want the visitor's IP, not 127.0.0.1
    xfp: req.get("x-forwarded-proto"),
  });
});

If the http:// URL is hard-coded (a CMS field, a .env value such as APP_URL=http://…, a database row from before you had HTTPS), no proxy setting changes it. Search the page source for http:// and fix the value at its origin. More framework guides are under hosting by framework.