Reverse proxy: Wrong port used to fetch css/js

(Guillaume Hetier) #1


I am trying to set up Caddy as a reverse proxy, for a Selfoss instace (an rss agreagator) served by nginx.

I use the following Caddyfile: {
  proxy / selfoss:8888 {

Here, selfoss:8888 refer to the selfoss container, where nginx listen to the port 8888.

When I try to load on my browser, I get the index file but the css and javascript file are not loaded: the files are requested at instead of
In the <head> of the index page, I have <base href="">.

Is there something missing in my configuration to correctly transmit which port was initially used?

I use Caddy 11.1 from this docker image :
Selfoss come from this docker image :

Looking on the sources of Selfoss, I finally understood that I had to set header_upstream X-Forwarded-Port correctly.

The following Caddyfile is working {
  proxy / selfoss:8888 {
    header_upstream X-Forwarded-Port 443

However, I now have two questions:

  • is there a way not to hardcode the port? The placeholder {port} does not represent the requested port.
  • is there a reason for header_upstream X-Forwarded-Port not to be included in transparent?


(Matthew Fay) #2

The {port} placeholder should be the port that Caddy’s client used to connect. Are you seeing different behaviour?

As far as I know, the only reason is that X-Forwarded-Port is pretty rare to see. I don’t think it’d hurt to have it added to the transparent preset, though. Perhaps you could open an issue on the Caddy repo so it can be discussed?

(Guillaume Hetier) #3

Thanks for you answer, Whitestrake.

It was different when I tried. I expected 443, for an https connection, but I get 58654.

I will open an issue about the transparent preset.

(Matthew Fay) #4

Huh… Does it change every time, or is it consistently port 58654? It might be the client’s port, not the port the client connected to Caddy on. That would make sense based on the wording, but it’s infinitely less useful for us who want to know the server port.

The server port information is available - it’s appended to the {host} placeholder (and specifically excluded by {hostonly}) - but if {port} isn’t it, then there’s no actual placeholder to get it on its own and it would be useful to have one!

When you open the issue on the transparent preset, mention that as well (and maybe link to this thread) - a PR for this issue might knock both problems over at once (implement the placeholder, and include X-Forwarded-Port in the the transparent preset).

(Guillaume Hetier) #5

It changed since yesterday, so it may not be different every time but it is not constant, but it stay the same when I reload the page.

I came to the same conclusion than you, {port} is probably the port on the client side. I have no idea what is the use of it, though.

Here is the issue I opened in the Caddy repos for those who are interested: