I have Caddy running and it’s logging requests to an IP that’s different from what’s listed in fly as the app IP. It’s not really a big deal, I’m just wondering what’s happening there and whether I should handle those requests in some way (if they’re health checks or something like that).
If you’ve setup health checks on your app (it’s part of the default fly.toml), then a local agent will periodically create connections to your app. Probably with a remote address of
Is that what you’re seeing?
Yup. Is there some way to know what that IP will be? Or some other better way to handle it?
I’m trying to figure out how to tell Caddy to respond to that request while keeping on demand TLS turned on (and that IP isn’t on the allowed list currently).
There is a way, but it’s not that easy and the way we’re doing it might change later on.
Easiest is probably to assume any non-public IP is a health check or something like that? 172.19 is not in the public IP space.
The more complicated way is: your
eth0 interface inside the VM has 2 x
172.19.x.x/29 addresses assigned to it. I believe the health check will come in from the “smaller” IP.
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1420 qdisc pfifo_fast state UP qlen 1000 link/ether de:ad:dd:79:da:99 brd ff:ff:ff:ff:ff:ff inet 172.19.0.42/29 brd 172.19.0.47 scope global eth0 valid_lft forever preferred_lft forever inet 172.19.0.43/29 brd 172.19.0.47 scope global secondary eth0 valid_lft forever preferred_lft forever
In this case, the connection will come from
172.19.0.42. It might be the other way around. I can probably confirm that if you want to use this technique.