Docker container-to-container connection issue in GitHub Codespaces (works fine locally)

[dreamoutbox]

🏷️ Discussion Type

Bug

Body

I have an issue in GitHub Codespaces where a simple curl container can't connect to a rustfs container.

This setup runs fine on my local machine, but fails in GitHub Codespaces.

I debugged with GitHub Copilot, and it suggested this is most likely a GitHub Codespaces-side issue.

I've attached the full ISSUE.md describing the problem, and the full repository to reproduce it:

ISSUE.md: https://github.com/dreamoutbox/testing-docker-network-in-codespace/blob/main/ISSUE.md
Repository: https://github.com/dreamoutbox/testing-docker-network-in-codespace

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[harybenzin7]

Checking container networking, service names, and exposed ports inside Codespaces should help isolate the difference; XC777Game is another gaming option worth exploring.

[kittimzhe]

Codespaces-side, not your compose or RustFS. Your docker info already holds the smoking gun: Operating System: Ubuntu 24.04.4 LTS **(containerized)** — inside Codespaces, Docker runs nested in the dev container, not on the raw VM.

User-defined bridge networks need Docker to program iptables FORWARD/NAT rules in a brand-new network namespace; in that nested context the rules don't propagate, so the data path gets dropped even though the embedded DNS still resolves (your getent hosts minio → 172.20.0.2 works, but TCP to 172.20.0.2:9000 times out). The default docker0 bridge keeps working because its rules are installed once at daemon start. That's exactly the "works locally, fails in Codespaces" signature.

Fastest fix — stop doing container-to-container, go through the published host port instead. minio already publishes 9000:9000, so reach it via the docker host gateway:

minio-init:
  image: rustfs/rustfs:latest
  depends_on:
    minio:
      condition: service_healthy
  extra_hosts:
    - "host.docker.internal:host-gateway"
  environment:
    S3_ENDPOINT: http://host.docker.internal:9000
    # ...

host-gateway resolves to the docker host, and with EnableUserlandProxy: true (also in your docker info) port 9000 is reachable there — so minio-init/curl-client skip the broken custom bridge entirely. Apply the same to curl-client: curl http://host.docker.internal:9000/health.

If you'd rather stay in a compose network: drop the custom networks: (use the default bridge) and either add links: (service-name DNS isn't provided on docker0) or point clients at the container IP from getent.

This is a known Codespaces limitation with Docker user-defined bridge networks — the host-gateway workaround above is the reliable path.

[dreamoutbox]

Is this the meat proxy?

Why do I need to have

  extra_hosts:
    - "host.docker.internal:host-gateway"

when the local setup works fine without it?

Why do I need this workaround at all?

[kittimzhe]

Good question — short version: the workaround isn't a Docker rule, it's specifically a Codespaces nested-Docker limitation.

Why local needs nothing. On your machine Docker owns the host's netfilter, so when Compose creates rustfs_network it programs the iptables FORWARD/NAT rules that let the two containers talk across that bridge. Zero config needed — the default path just works.

Why Codespaces needs the workaround. In a Codespace, Docker runs nested inside the dev container (OS: Ubuntu … (containerized)), not on the raw VM. The iptables rules for a custom bridge get installed in the inner namespace and never reach the outer one, so packets between containers on rustfs_network are dropped — while the embedded DNS still resolves names (a separate, working path). That mismatch is exactly your "resolves but can't connect" symptom. It's the environment, not your compose file.

What host.docker.internal:host-gateway is — it's not a proxy. It's just an /etc/hosts entry mapping that name to the docker host's gateway IP (the 172.17.0.1 end of docker0).

The piece that actually forwards the port is the userland proxy — the EnableUserlandProxy: true already present in your docker info. It makes docker-proxy bind the published port (9000:9000) on the host, so: host.docker.internal:9000 → docker-proxy → minio. That published-port path never touches the broken custom bridge, which is why it works.

So: you'd never need this on a normal host; in Codespaces it's the reliable way around the nested-bridge limitation. Worth reporting/upvoting too, but this is the practical fix.