Skip to content

Nuface Blog

隨意隨手記 Casual Notes

Menu
  • Home
  • About
  • Services
  • Blog
  • Contact
  • Privacy Policy
  • Login
Menu

How Docker Containers Communicate Using Container Names

Posted on 2025-11-06 by Rico

When running multiple Docker containers, one common question is:
“Can containers connect to each other using their container names?”
The answer is Yes!
But — only if they are on the same custom Docker network.


1. Why the Default Network Doesn’t Work

By default, Docker creates a bridge network (also known as docker0).
However, this default bridge network does not support automatic DNS name resolution,
so containers can only communicate using IP addresses.

That’s fine for quick tests, but IPs change often, making it hard to maintain.


2. Create a Custom Network

To enable name-based communication, create a custom network:

docker network create mynet

Containers attached to this network will be able to resolve each other’s names automatically.


3. Attach Containers to the Same Network

Run containers on that network:

docker run -d --name web --network mynet nginx
docker run -d --name app --network mynet alpine sleep infinity

Both web and app are now on mynet.


4. Connect via Container Names

Enter one container (e.g. app) and test the connection:

docker exec -it app sh
ping web
nc -zv web 80

Docker’s internal DNS will resolve web to the web container’s IP automatically.
No need to remember IPs — just use the container name!


5. Using Network Aliases

If you want a shorter or alternate name, set a network alias:

docker run -d --name db --network mynet --network-alias mysql mysql:8

Now other containers can reach it using the name mysql.


✅ Summary

ConditionDescription
Same custom networkEnables DNS name resolution
Default bridgeNo name resolution, IP only
Use aliasOptional alternate names

In short:

When containers share the same custom Docker network, they can communicate over TCP/UDP using container names or aliases — no IP required.

Recent Posts

  • Postfix + Let’s Encrypt + BIND9 + DANE Fully Automated TLSA Update Guide
  • Postfix + Let’s Encrypt + BIND9 + DANE TLSA 指紋自動更新完整教學
  • Deploying DANE in Postfix
  • 如何在 Postfix 中部署 DANE
  • DANE: DNSSEC-Based TLS Protection

Recent Comments

  1. Building a Complete Enterprise-Grade Mail System (Overview) - Nuface Blog on High Availability Architecture, Failover, GeoDNS, Monitoring, and Email Abuse Automation (SOAR)
  2. Building a Complete Enterprise-Grade Mail System (Overview) - Nuface Blog on MariaDB + PostfixAdmin: The Core of Virtual Domain & Mailbox Management
  3. Building a Complete Enterprise-Grade Mail System (Overview) - Nuface Blog on Daily Operations, Monitoring, and Performance Tuning for an Enterprise Mail System
  4. Building a Complete Enterprise-Grade Mail System (Overview) - Nuface Blog on Final Chapter: Complete Troubleshooting Guide & Frequently Asked Questions (FAQ)
  5. Building a Complete Enterprise-Grade Mail System (Overview) - Nuface Blog on Network Architecture, DNS Configuration, TLS Design, and Postfix/Dovecot SNI Explained

Archives

  • December 2025
  • November 2025
  • October 2025

Categories

  • AI
  • Apache
  • Cybersecurity
  • Database
  • DNS
  • Docker
  • Fail2Ban
  • FileSystem
  • Firewall
  • Linux
  • LLM
  • Mail
  • N8N
  • OpenLdap
  • OPNsense
  • PHP
  • QoS
  • Samba
  • Switch
  • Virtualization
  • VPN
  • WordPress
© 2025 Nuface Blog | Powered by Superbs Personal Blog theme