Caddy not redirecting http requests

[tutley (Tom Utley)]

Hi everyone,

I setup caddy server (0.10.10) on an AWS instance running Ubuntu a couple of weeks ago and everything seemed to be working fine. I’m serving a couple of static sites as well as reverse proxying a couple of apps using caddy, and now I have automatic TLS! Yay! (Also I really like the http2)

Anyway, while I remember testing this and it working initially, today I’ve noticed that http redirects don’t seem to be working. I might have tested this the wrong way by using a web browser instead of using curl (initially) but now when I curl to a domain that I own I simply get “connection refused” every time.

The way I understand it, I should get a redirect to the https version of the domain. If that’s not the default behavior, then please let me know how to configure that behavior. I have tried several alternate configurations, including specifying http://domain… and using redir. Nothing has worked. HTTPS is working for all of my domains, which is great, but http redirects are simply not working. Any help is appreciated!

Caddyfile:

fishincoach.com www.fishincoach.com {
    tls tom@tomutley.com
    root /home/ubuntu/web/fishincoach
    log fishincoach.access.log
}

# (repeat same pattern for static sites)

foundirl.com www.foundirl.com {
  tls tom@tomutley.com
  push
  proxy / http://localhost:6000
  log foundirl.access.log
}

# (repeat same pattern for proxy sites)

Netstat:
sudo netstat -tlp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 localhost:27017 : LISTEN 1048/mongod
tcp 0 0 :ssh : LISTEN 1053/sshd
tcp 0 0 localhost:5500 : LISTEN 21709/server.js
tcp6 0 0 [::]:http [::]: LISTEN 6120/caddy
tcp6 0 0 [::]:x11 [::]:* LISTEN 30514/foundirl
tcp6 0 0 [::]:ssh [::]:* LISTEN 1053/sshd
tcp6 0 0 [::]:https [::]:* LISTEN 6120/caddy

[tutley (Tom Utley)]

By the way, the log when starting the server:

3|caddy    | Activating privacy features...
3|caddy    |  done.
3|caddy    | https://fishincoach.com
3|caddy    | https://www.fishincoach.com
3|caddy    | https://foundirl.com
3|caddy    | https://www.foundirl.com
3|caddy    | http://fishincoach.com
3|caddy    | http://www.fishincoach.com
3|caddy    | http://foundirl.com
3|caddy    | http://www.foundirl.com
...

[tutley (Tom Utley)]

One more thing: If I run: sudo tcpdump -nni eth0 port 80

I do see the incoming http requests

[tutley (Tom Utley)]

Wow. Somehow this ancient iptables rule came back from the dead. This was the problem.

iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
REDIRECT   tcp  --  anywhere             anywhere             tcp dpt:http redir ports 3000

[matt (Matt Holt)]

Thanks for coming back to share how you fixed it!

[tutley (Tom Utley)]

I deleted that rule and then ran iptables-save

But I wasn’t satisfied as this problem had occurred really randomly. I haven’t used a port forward to 3000 since I used to run a nodejs-based reverse proxy which has been a long time. Before Caddy I had been using nginx for at least a couple of years.

Anyway, sure enough:
# grep -rnw ‘/etc’ -e ‘iptables’
/etc/default/ufw:34:# only enable if using iptables backend
/etc/init/ufw.conf:3:# The Uncomplicated Firewall is a front-end for iptables, to make managing a
/etc/rc.local:13:iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3000

The rule must have come back from the dead after I did a mandatory security update and rebooted the server. I deleted that line from rc.local so hopefully this won’t happen again.