O mais fácil para mim foi definir um rótulo extra no app.yml do Discourse para dizer ao meu Traefik para adicionar um cabeçalho X-Forwarded-Proto: https, mas então o nginx substituiria esse parâmetro pela sua própria versão.
E a configuração do nginx do Discourse desempenha um papel aqui:
Lá, o Discourse tenta adivinhar o protocolo da solicitação original (que, na minha configuração, é sempre texto puro, já que é isso que o Traefik envia). E então usa isso para definir o X-Forwarded-Proto várias vezes.
No final, editei meu containers/app.yml para codificar esses cabeçalhos para https:
run:
- exec: echo "Beginning of custom commands"
## If you want to set the 'From' email address for your first registration, uncomment and change:
## After getting the first signup email, re-comment the line. It only needs to run once.
# - exec: rails r "SiteSetting.notification_email='no-reply@forum.cabana.network'"
- replace:
filename: "/etc/nginx/conf.d/discourse.conf"
from: /# attempt to preserve the proto, must be in http context\nmap \$http_x_forwarded_proto \$thescheme {\n default \$scheme;\n "~https$" https;\n}/\n
to: |
# force https scheme so Discourse generates HTTPs links and redirects (ie, `/login`)
- replace:
filename: "/etc/nginx/conf.d/discourse.conf"
from: "$thescheme"
global: "true"
to: "https"
- exec: echo "End of custom commands"
Mais uma vez, acho que se houver uma configuração force_https, o Discourse-the-rails-app deveria honrá-la, independentemente do que o proxy reverso ou outras partes lidam ou não.