Accessing internal Ubuntu/Caddy web server from another PC on LAN

1. Caddy version (caddy version):

v2.4.6 h1:HGkGICFGvyrodcqOOclHKfvJC0qTU7vny/7FhYp9hNw=

2. How I run Caddy:

As a service: sudo systemctl start caddy

a. System environment:

Ubuntu 21.10

b. Command:

sudo systemctl start caddy

c. Service/unit/compose file:

n/a

d. My complete Caddyfile or JSON config:

http://localhost {
        root * /var/www/html/php
        php_fastcgi unix//run/php/php8.0-fpm.sock
        file_server
        encode gzip zstd
        log {
                output file /var/log/caddy/access.log {
                        roll_size 3MiB
                        roll_keep 5
                        roll_keep_for 48h
                }
                format console
        }
        encode gzip zstd
}

3. The problem I’m having:

I am trying to access my website on my Ubuntu web server from a different PC on the network. I have verified that on the web server I can type curl -v localhost and get the “Hello World” results I am looking for. So PHP is working correctly on the web server. On my second PC, I have tried the IP of the web server in the address bar and a domain name ecgoinc.localhost after I added 192.168.0.100 ecgoinc.localhost to my hosts file. It just says “unable to connect” in the browser. Now I did just test curl from my second PC. curl -v 192.168.0.100 and got this result:

* Rebuilt URL to: 192.168.0.100/
*   Trying 192.168.0.100...
* TCP_NODELAY set
* Connected to 192.168.0.100 (192.168.0.100) port 80 (#0)
> GET / HTTP/1.1
> Host: 192.168.0.100
> User-Agent: curl/7.55.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: Caddy
< Date: Mon, 22 Nov 2021 04:50:14 GMT
< Content-Length: 0
<
* Connection #0 to host 192.168.0.100 left intact

Maybe this is not a Caddy problem and maybe it is a just a setting in my network config. I know I’m close, but stuck on how to get this to work.

4. Error messages and/or full log output:

After I did that curl from the second PC, I got this in the log file:

1.6375572635589192e+09  info    http.log.access handled request {"request": {"remote_addr": "192.168.0.130:59446", "proto": "HTTP/1.1", "method": "GET", "host": "192.168.0.100", "uri": "/", "headers": {"User-Agent": ["curl/7.55.1"], "Accept": ["*/*"]}}, "common_log": "19
2.168.0.130 - - [22/Nov/2021:05:01:03 +0000] \"GET / HTTP/1.1\" 0 0", "user_id": "", "duration": 0.000013111, "size": 0, "status": 0, "resp_headers": {"Server": ["Caddy"]}}

5. What I already tried:

Changed the domain part of the caddyfile several times.

6. Links to relevant resources:

You’re using localhost as the host matcher, so if you make a request with an IP address, it won’t match.

If you want to allow requests with any hostname, then just use http:// as your site address.

1 Like

OK, that got me further. Now when I do a ‘curl -v’ with the IP or the domain, I do get my html code with the ‘Hello World’ printed correctly from the PHP code on the second computer. But when I tried and hit either the IP or the domain from a browser, it redirects to the https version and says “unable to connect”.

1 Like

Probably because your browser is caching a redirect to HTTPS. Use curl to verify it’s the browser causing the redirect.

1 Like

OK, I cleared all cookies/cache/history etc and tried to load both IP and domain and it keeps reverting to https and says “unable to connect”. Curl does indeed work fine with the IP address.

So then I opened up Chrome which I rarely use and have never used with this specific site. The domain would not load, but the IP address did load and displayed “Hello World” as expected. So seems like a caching issue and my hosts file is not correctly routing the domain for some reason. Maybe I need a reboot.

1 Like

OK, IP address now working in Firefox as well after the reboot! I must be doing the hosts file wrong or something!

This is my line in C:\Windows\System32\drivers\etc\hosts:
192.168.0.100 ecgoinc.localhost

That is right, right?

1 Like

Some browsers always resolve *.localhost to 127.0.0.1 (as they should, frankly). You shouldn’t be trying to fight that. Use a different TLD instead.

2 Likes

That was it! All is working as it should now! Thank you so much for all your help!!

1 Like

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