Lo más fácil para mí fue configurar una etiqueta adicional en app.yml de Discourse para indicarle a mi Traefik que agregara una cabecera X-Forwarded-Proto: https, pero luego nginx anularía ese parámetro con su propia versión.
Y la configuración de nginx de Discourse juega un papel aquí:
Aquí Discourse intenta adivinar el protocolo de la solicitud original (que, en mi configuración, siempre es texto plano ya que eso es lo que envía Traefik). Y luego lo usa para establecer el X-Forwarded-Proto varias veces.
Al final, edité mi containers/app.yml para codificar esas cabeceras como 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"
Una vez más, creo que si hubiera una configuración force_https, Discourse-la-aplicación-rails debería respetarla, independientemente de lo que el proxy inverso u otras partes manejen o no.