Log the request before reverse_proxy

Help
1

1. Caddy version (caddy version):

2.4.6

2. How I run Caddy:

a. System environment:

Ubuntu 20.04

b. Command:

caddy run \
    --config ${HOME}/conf/caddy/CaddyFile \
    --adapter caddyfile \
    --pidfile ${HOME}/var/run/caddy.pid \
    --environ

c. Service/unit/compose file:

d. My complete Caddyfile or JSON config:

:9130 {
	log {
		level DEBUG
		output file {$HOME}/log/caddy/history_access.log
	}

	route /history/* {
		uri strip_prefix /history
		reverse_proxy {
			header_up Host {upstream_hostport}
			to https://example1.com
		}
	}
	route /auth/* {
		uri strip_prefix /auth
		reverse_proxy {
			header_up Host {upstream_hostport}
			to https://example2.com
		}
	}
}

3. The problem I’m having:

I have to reverse proxy into https://example1.com and https://example2.com for different routes, I am using this configuration to hide the reverse proxy endpoints in my app. For me the /auth route works correctly, but the /history returns a 404 I did a curl request with the full correct url

https://example1.com/xx/yy

and that works well, now when I replace the curl with

http://localhost:9130/history/xx/yy

I get a 404 from the origin

Is there a way I can dump the full request (with the modified reverse proxied url) so I can see what is actually being sent to the reverse proxy

At first for me the /auth was also failing, then I finally figured out the Host header has to be modified because the origin is https
so I added

header_up Host {upstream_hostport}

which fixed it for me. but now the /history fails with 404, so I am looking for some debugging ideas on how I can dump out the request so I can see exactly which endpoint is called on the reverseproxy

2

You can turn on the debug global option to see more detailed logs, including information from the reverse_proxy module just before it proxies the request.

Also worth mentioning, you can simplify your config by using handle_path instead of route + uri strip_prefix, since it has built-in path prefix stripping logic.

In general though, most apps don’t behave well when the path prefix is stripped:

1 Like
3

the debug option was very helpful I finally figured it out I had to do this

-header_up Host {upstream_hostport}
+header_up Host {http.reverse_proxy.upstream.host}

it was wierd that the origin was returning a 404 when the Host header was example.com:443 but it works when it is just example.com

is there a shortcut for

http.reverse_proxy.upstream.host

just like how

upstream_hostport

is a shortcut for

http.reverse_proxy.upstream.hostport

I tried upstream_host and that did not seem to work

4

Those shortcuts are actually called placeholders in case you wondered :slight_smile:
Here is the full list (hotlink to #placeholders)

But no, there is no placeholder for http.reverse_proxy.upstream.host.

However, those are defined in the following file and could easily be extended by filing a Pull Request. Maybe @matt could share his thoughts about the idea of adding some more placeholders :innocent:

5

That is neat. Thanks for the quick response.

1 Like
6

Actually, {http.reverse_proxy.upstream.host} does exist, it’s just that there’s no Caddyfile shortcut for that placeholder, but you can still use the long-form. See all the reverse_proxy placeholders in the JSON docs:

2 Likes
7

This topic was automatically closed after 30 days. New replies are no longer allowed.