Reverse_proxy, / works, nothing else is forwarded, logs not great

[voltagex (Adam Baxter)]

Caddy 2.8.4 built with xcaddy.

{
	debug
	log default {
		output stdout
		format console
		level DEBUG
	}
}

http://localhost:8088/ {
	templates
	log {
		level DEBUG
	}
	handle {
		reverse_proxy /* debian:80
	}
}

debian:80 is running docker run -p 80:80 kennethreitz/httpbin - this is working correctly

This container should have Javascript, CSS, other routes etc

 curl.exe -vv http://localhost:8088/spec.json
* Host localhost:8088 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
*   Trying [::1]:8088...
* Connected to localhost (::1) port 8088
> GET /spec.json HTTP/1.1
> Host: localhost:8088
> User-Agent: curl/8.9.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: Caddy
< Date: Sun, 27 Oct 2024 12:53:43 GMT
< Content-Length: 0
<
* Connection #0 to host localhost left intact

A few concerns:

• Why is / working but /spec.json not?
• Caddy shouldn’t return 200 OK when nothing is being sent to the upstream, this trips me up all the time
• Shouldn’t the logging settings there be showing me that there’s a problem?

2024/10/27 12:53:43.552 INFO    http.log.access.log0    NOP     {"request": {"remote_ip": "::1", "remote_port": "54719", "client_ip": "::1", "proto": "HTTP/1.1", "method": "GET", "host": "localhost:8088", "uri": "/spec.json", "headers": {"User-Agent": ["curl/8.9.1"], "Accept": ["*/*"]}}, "bytes_read": 0, "user_id": "", "duration": 0, "size": 0, "status": 0, "resp_headers": {"Server": ["Caddy"]}}

is all I see.

[skip2networks (Alex Lee)]

Hi there!

A couple of questions that would help:

1. You note that you built with xcaddy - what custom modules did you include?
2. You have templates in your configuration under localhost:8088 which sticks out to me, since you’ve got a reverse_proxy under it. What is the goal here?

The issue you’re having with the / endpoint working but nothing else is due to your site block including a path. Any requests that don’t match http://localhost:8088/ exactly won’t be matched and won’t be proxied.

The Caddy logs should warn you of this on startup (This is from my own instance):
2024/10/27 15:29:20.046 WARN caddyfile Using a path in a site address is deprecated; please use the 'handle' directive instead {"address": "http://localhost:8088/"}

This must be changed:

http://localhost:8088/ {
	templates
	log {
		level DEBUG
	}
	handle {
		reverse_proxy /* debian:80
	}
}

Omitting the / after the port:

http://localhost:8088 {
	templates
	log {
		level DEBUG
	}
	handle {
		reverse_proxy /* debian:80
	}
}

By default, Caddy will return 200 for unmatched routes.

Is there any reason that you can’t simplify your Caddyfile, like such:

http://localhost:8088 {
	log {
		level DEBUG
	}
	reverse_proxy * debian:80
}

Again, I’m not completely sure what your end goal is using templates, so it might help to add context.

[voltagex (Adam Baxter)]

@skip2networks

The Caddy logs should warn you of this on startup

I’ll check tomorrow but I don’t think I’m seeing that.

@skip2networks

You have templates in your configuration

I was chasing another bug - I can remove and retest.

@skip2networks

By default, Caddy will return 200 for unmatched routes.

I hope this can be changed.

[francislavoie]

@voltagex

I hope this can be changed.

That will never change. It’s part of Caddy’s design. You just need to look at your logs to recognize what Caddy is doing, and notice the warnings telling you not to use deprecated features.

Alex is spot on here, the issue is your / in the site address. This makes it match only requests to / and nothing else. That feature is deprecated, and will be removed soon (made an error).

Also, you can simplify the proxy to only reverse_proxy debian:80, no need for a matcher if you have it handle all routes.

@voltagex

	log {
		level DEBUG
	}

There’s no DEBUG level for access logs, do you can simplify this to simply log.