Today I hit one of those sneaky Docker networking issues that nearly drove me up the wall. Maybe this’ll save someone else from the same hours of head-scratching.
I have an php application container that had been running fine, until it suddenly couldn’t connect to one of its internal services anymore. In my case, the service was Redis, but honestly, it could’ve been any containerized service: a database, queue, or some internal API.
Everything was on the same Docker network (services), managed via Portainer. The Redis container was healthy. Other containers could reach it. But this one app? Timeouts. No errors in the logs, just silence.
The Head-Scratcher
- DNS resolved correctly
- The service container was pingable from others
- Internal IPs and ports were fine
- Restarting containers? Didn’t help
- The app could reach other containers, just not this one
The Real Problem: A Stale MAC Address
After a ton of digging and search, I found an issue on Github that was that Portainer was using an identical MAC address for my redis container as the app with connectivity issue. I don’t know how this happened, but I have the clue that me restarting my redis container earlier in the morning triggered this wrong MAC assignment. The result? ARP-level chaos. Docker didn’t complain. Logs didn’t show it. But network packets from this app were silently being misrouted or dropped.
Once I removed the network from my container and reattached it, the issue was resolved and everything snapped back to life.
The Lesson
If you’re managing containers in Portainer and one of them suddenly can’t talk to another container, even though they’re on the same network, check this:
- Open your Networks tab
- Look for duplicate MAC addresses, if you’re facing the same issue, you’d probably find two of your containers are having the same MAC.
- Remove the Network from one of the containers.
- Attach the network again, this should use a different MAC Address and your containers should be able to talk again.
I hope this could save you an afternoon of debugging what looks like a service failure but is really a network identity mix-up caused.