Reverse proxy: Wrong port used to fetch css/js

Hi,

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:

rss.domain.com {
  proxy / selfoss:8888 {
    transparent
  }
}

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

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

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

I use Caddy 11.1 from this docker image : https://hub.docker.com/r/abiosoft/caddy
Selfoss come from this docker image : https://hub.docker.com/r/hardware/selfoss


EDIT:
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

rss.domain.com {
  proxy / selfoss:8888 {
    transparent
    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?

Thanks,
Nephe

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? Sign in to GitHub · GitHub

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.

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).

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:
https://github.com/mholt/caddy/issues/2412

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.