This configuration might fix the generated URLs, but it does not solve the underlying issue that Phoenix does not know that the server was actually reached via HTTPS. As a result, certain security features are not enabled. In particular, (session) cookies do not get the secure option that is meant to prevent them from leaking in plaintext HTTP requests.

For more details, see TLS Vulnerabilities | EEF Security WG

The better solution is the use of HTTP headers to pass the external scheme and port from the reverse proxy to the application, as suggested by @ibarch

The URL generation is controlled by the Endpoint configuration (specifically the :url option). The value is configured in runtime.exs by default. This option only controls URL generation (for links in the app), it does not configure the webserver (that’s the :http option right below it).

I’m assuming from your post that you changed it thinking it was the webserver configuration, so if that’s the case changing it back to the default should resolve the problem

(Also: If this is the case, the links in your app should all be wrong too, right?)

For the record, you could also pass a few other things into url/2 if you needed to, like a conn / socket, a different endpoint, or a URI. But I don’t think that’s what you need here.

Not sure I understand what you mean here. X-Forwarded-For contains the original client IP address(es) from the original request (and any proxies in between). The host/port are sent via the Host header, which I assume Nginx just passes along in the proxied request.

Either way, by default the URL generation is controlled by the Endpoint config.

So I think the confusion has been explained. The scheme option worked as expected, but it seems that the port from the http config gets used for url generation as well, so I had to explicitly set it to 443. Thanks for the help, this is what the config looks like in case anyone else gets confused:

config :myapp, MyappWeb.Endpoint,
  url: [
    scheme: "https",
    host: "myapp.com",
    port: 443
  ],
  http: [port: 5000]

Also, to explain why I never noticed it from links in the application itself, it’s because they only need ~p unlike links in e-mails, which need the full url, so the incorrect options never manifested.