Django DisallowedHost and CSRF 403 after deploy: what Django is checking.

With DEBUG = False the browser only shows a short page. The useful line is in the app’s log. Match it here:

On Canner, Caddy terminates HTTPS and forwards each request to your app on 127.0.0.1. It passes the Host header through unchanged, so Django sees the host the visitor typed: your-project.canner.app or your custom domain. It also sets X-Forwarded-Proto: https, X-Forwarded-For and X-Forwarded-Host, and it drops any X-Forwarded-* values a client tries to send itself.

Django is started with gunicorn --bind 127.0.0.1:$PORT <project>.wsgi:application (see the Python docs; list gunicorn in requirements.txt). Gunicorn trusts X-Forwarded-Proto from 127.0.0.1 and ::1 by default and marks those requests as https, so request.is_secure() is already true on a standard deploy. That is why many Django apps on Canner never hit the CSRF error at all.

Set SECURE_PROXY_SSL_HEADER anyway. When Canner can’t find a package holding wsgi.py next to manage.py, it falls back to manage.py runserver, which doesn’t read the header. The setting also keeps your app correct if you ever change the server or its forwarded_allow_ips.

• `.canner.app` in `ALLOWED_HOSTS` covers previews. A pull-request preview lives at branch--project.canner.app, which the leading dot matches. Caddy only routes your own project’s hostnames to your app, so the wildcard doesn’t let another project’s traffic in.
• `www` doesn’t need an entry when Serve www is on. Canner answers www.example.ca with a 301 to example.ca before Django sees it (custom domains).
• **Never put https://*.canner.app in CSRF_TRUSTED_ORIGINS.** Other customers’ apps live on that domain, and the setting tells Django to accept their POSTs. List exact origins. For a preview, its own address is in CANNER_URL.
• Same-origin forms need no `CSRF_TRUSTED_ORIGINS` at all once Django sees HTTPS. The list is for a frontend on one domain posting to Django on another.

# settings.py
import os

DEBUG = False

# The Host header Django sees is the one the visitor typed.
ALLOWED_HOSTS = [".canner.app", "example.ca"]

# Tell Django the request was HTTPS when the proxy says so.
SECURE_PROXY_SSL_HEADER = ("HTTP_X_FORWARDED_PROTO", "https")
SESSION_COOKIE_SECURE = True
CSRF_COOKIE_SECURE = True

# Only for forms or fetch() calls that POST from ANOTHER origin.
# Full origins, scheme included: "https://app.example.ca,https://admin.example.ca"
CSRF_TRUSTED_ORIGINS = [
    o for o in os.environ.get("CSRF_TRUSTED_ORIGINS", "").split(",") if o
]

Canner’s health check calls your app on http://localhost:<port>/ (the path is a project setting) and counts any status below 500 as alive. Django answers that probe with a 400 when localhost isn’t allowed, so the deploy succeeds, then every visitor gets Bad Request (400). Don’t add localhost to quiet it; the check is doing its job, and the fix is the real hostnames.

The build log already warns you: [canner] ⚠ django checks the Host header — if every request fails (Django: 400 Bad Request / DisallowedHost; Rails, Sinatra: "Blocked hosts"), allow this app's host and your custom domain:, followed by a suggested ALLOWED_HOSTS line with your app’s <project>.canner.app address.

Run these from your machine and from the project. check --deploy flags the missing secure-cookie and HTTPS settings in one pass. The CLI streams the app’s log so you can see the exact Invalid HTTP_HOST or Forbidden (…) line as it happens. Set CSRF_TRUSTED_ORIGINS with canner env set or in the dashboard’s environment variables, then redeploy.

# What does Django answer for each host?
curl -sI https://your-project.canner.app/ | head -1
curl -sI https://example.ca/ | head -1

# Django's own pre-flight list for production settings
python manage.py check --deploy

# Watch the app's log while you reproduce the error
canner logs --follow

The cause is the same anywhere a proxy or load balancer ends TLS: Django gets plain HTTP and a hostname it wasn’t told about. What differs is whether the server in front of Django already sets the scheme (gunicorn does, for connections from loopback) and whether the platform rewrites Host. More framework notes are under hosting by framework and on the Django hosting page.