Fly.io keeps saying my app isn't listening, but it totally is?

[TechDragon]

I’m scratching my head here. Been trying to deploy a Django app and Fly.io keeps insisting my app “is not listening on the expected address” but when I SSH in and check… it’s definitely there!

Here’s what Fly.io tells me:

WARNING The app is not listening on the expected address and will not be reachable by fly-proxy.
You can fix this by configuring your app to listen on the following addresses:
  - 0.0.0.0:8000
Found these processes inside the machine with open listening sockets:
  PROCESS        | ADDRESSES
-----------------*--------------------------------------
  /.fly/hallpass | [fdaa:39:7402:a7b:f5:8b8:4bcd:2]:22

But when I SSH in and check myself:

$ ps aux | grep gunicorn
root  676  /app/.venv/bin/python /app/.venv/bin/gunicorn config.wsgi:application --bind 0.0.0.0:8000

$ netstat -tlnp
tcp  0  0  0.0.0.0:8000  0.0.0.0:*  LISTEN  676/python
tcp6 0  0  fdaa:39:7402:a7b:f5::22  :::*  LISTEN  642/hallpass

$ curl -w '%{http_code}' http://localhost:8000/
301

So my app is definitely running, listening on port 8000, and responding to requests. What gives?

My setup is pretty standard:

• Django + Wagtail + Gunicorn
• fly.toml has internal_port = 8000 and PORT = "8000"
• Gunicorn started with --bind 0.0.0.0:8000

I’ve tried everything I can think of:

• Different health check paths
• Direct gunicorn vs shell scripts
• Various timeouts and grace periods
• Removing health checks entirely

The app works great when I test it locally in the container, but Fly.io’s proxy just can’t seem to find it.

Anyone else run into this?

Thanks in advance!

[lubien]

It might be a case of your app just taking a few seconds more to bind during deployments.

If you go to logs and errors dashboard page do you still see Fly Doctor UI telling you that there are problems reaching your app via proxy?

[halfer]

Hmm, if your app is working, my first thought is probably wrong. But I will mention it anyway, in case it stimulates any related thinking. It looks like you’re listening on an IPv4 address, and I wonder if you need to be listening on an IPv6 address.

In Apache I use *:8000, and it looks like as a result it is listening on both IPv4 and IPv6.

[TechDragon]

Not sure exactly what I really changed since it was before I did my initial commit… but I tweaked something and while doing entirely new deployments, it just started working.