HTTP to an internal hostname in V2

1. Caddy version (caddy version):

Latest version of official caddy container

2. How I run Caddy:

Docker image
v2.0.0 h1:pQSaIJGFluFvu8KDGDODV8u4/QRED/OPyIR+MWYYse8=

a. System environment:

Microsoft Windows [Version 10.0.18363.836]
Docker Desktop 2.3.0.2

b. Command:

docker start caddy
CDM inside ther container is "caddy run --config /etc/caddy/Caddyfile --adapter caddyfile"

c. Service/unit/compose file:

N/A

d. My complete Caddyfile or JSON config:

http://local.airsonic {
	encode gzip
	log {
		output file /logs/airsonic.log
		format single_field common_log
	}
	reverse_proxy 192.168.1.103:4040
}

3. The problem Iā€™m having:

Not responding to HTTP requests inside my network. local.airsonic is in my host file. Ping reponds to the correct internal IP address. This had worked for me in V1.

4. Error messages and/or full log output:

{"level":"info","ts":1590669944.6168828,"msg":"using provided configuration","config_file":"/etc/caddy/Caddyfile","config_adapter":"caddyfile"}
{"level":"info","ts":1590669944.6199634,"logger":"admin","msg":"admin endpoint started","address":"tcp/localhost:2019","enforce_origin":false,"origins":["localhost:2019","[::1]:2019","127.0.0.1:2019"]}
2020/05/28 12:45:44 [INFO][cache:0xc0007eff90] Started certificate maintenance routine
{"level":"info","ts":1590669944.626107,"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}
{"level":"info","ts":1590669944.8049014,"logger":"tls","msg":"cleaned up storage units"}
{"level":"info","ts":1590669944.8070617,"msg":"autosaved config","file":"/config/caddy/autosave.json"}
{"level":"info","ts":1590669944.8070824,"msg":"serving initial configuration"}

5. What I already tried:

I also tried local.airsonic:80 instead of http://local.airsonic, but it had no effect.

6. Links to relevant resources:

N/A

is this upstream using HTTP or HTTPS?
if HTTP you might need to specify it with

reverse_proxy http://192.168.1.103:4040

if HTTPS you might need to trust the certificate (if no issued by known CA)

reverse_proxy 192.168.1.103:4040 {
    transport http {
        tls_insecure_skip_verify
    }
}

Not necessary, HTTP is the default for all proxy upstreams.

Sounds like a network misconfiguration.

I agree it does sound like a network config issue. Sounds like the caddy config is correct. Wanted to make sure there was not a change in v2 I missed.

May just need to step away from it for a day so I can come back to it and find my mistake.

1 Like

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