1. Caddy version (caddy version
):
caddy-2.3.0-alpine
2. How I run Caddy:
In a docker container, on Docker Desktop for Windows using WSL2. Proxying to a GRPC service running on server:5300, defined in the docker-compose via which caddy is run. (Caddy also proxies the HTTP API on server:8000 which works great)
a. System environment:
Docker Desktop For Windows using WSL2.
b. Command:
c. Service/unit/compose file:
d. My complete Caddyfile or JSON config:
:80 {
route /host.Service/* {
reverse_proxy h2c://server:5300
}
}
3. The problem Iām having:
I am trying to reverse proxy to a GRPC service running in a docker-container in the same network as caddy. Caddy also proxies the HTTP service on the same container running on another port but has been failing to proxy the GRPC service.
I do wish to retain the route matching as I want to proxy two different grpc services running on the server along with other apis.
4. Error messages and/or full log output:
caddy_1 | {"level":"info","ts":1615299387.2791378,"msg":"using provided configuration","config_file":"/etc/caddy/Caddyfile","config_adapter":"caddyfile"}
caddy_1 | {"level":"info","ts":1615299387.2818875,"logger":"admin","msg":"admin endpoint started","address":"tcp/localhost:2019","enforce_origin":false,"origins":["localhost:2019","[::1]:2019","127.0.0.1:2019"]}
caddy_1 | {"level":"info","ts":1615299387.2822866,"logger":"http","msg":"server is listening only on the HTTP port, so no automatic HTTPS will be applied to this server","server_name":"srv0","http_port":80}
caddy_1 | {"level":"info","ts":1615299387.2824018,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0xc00045d960"}
caddy_1 | {"level":"info","ts":1615299387.2833426,"logger":"tls","msg":"cleaned up storage units"}
caddy_1 | {"level":"info","ts":1615299387.2833781,"msg":"autosaved config","file":"/config/caddy/autosave.json"}
caddy_1 | {"level":"info","ts":1615299387.283404,"msg":"serving initial configuration"}
caddy_1 | {"level":"info","ts":1615299395.5737286,"logger":"http.log.access.log0","msg":"handled request","request":{"remote_addr":"172.18.0.1:46468","proto":"HTTP/2.0","method":"PRI","host":"","uri":"*","headers":{}},"common_log":"172.18.0.1 - - [09/Mar/2021:14:16:35 +0000] \"PRI * HTTP/2.0\" 0 0","duration":0.0000111,"size":0,"status":0,"resp_headers":{"Server":["Caddy"]}}
caddy_1 | {"level":"info","ts":1615299396.5881245,"logger":"http.log.access.log0","msg":"handled request","request":{"remote_addr":"172.18.0.1:46472","proto":"HTTP/2.0","method":"PRI","host":"","uri":"*","headers":{}},"common_log":"172.18.0.1 - - [09/Mar/2021:14:16:36 +0000] \"PRI * HTTP/2.0\" 0 0","duration":0.0000091,"size":0,"status":0,"resp_headers":{"Server":["Caddy"]}}
caddy_1 | {"level":"info","ts":1615299397.9144454,"logger":"http.log.access.log0","msg":"handled request","request":{"remote_addr":"172.18.0.1:46476","proto":"HTTP/2.0","method":"PRI","host":"","uri":"*","headers":{}},"common_log":"172.18.0.1 - - [09/Mar/2021:14:16:37 +0000] \"PRI * HTTP/2.0\" 0 0","duration":0.000012,"size":0,"status":0,"resp_headers":{"Server":["Caddy"]}}
5. What I already tried:
Using the route /*
to and verified if the GRPC traffic is proxied resulted in the same behaviour as noted in the logs above.