When you deploy a game server in Docker, networking is the single most important thing to get right or your players cannot connect at all. This guide explains how Docker networking works for Minecraft and other game servers, how TCP and UDP ports differ, what allocations really mean, and how M.A.F Cloud automates port bindings with live port probes so you never guess again.
Most hosting problems come down to one of three things: wrong protocol selected (TCP instead of UDP), firewall blocking the port, or container ports not mapped to host ports correctly. By the end of this article, you will know exactly which port numbers to use, how to set BOTH protocol when needed, why Pterodactyl uses allocations while traditional panels don't, and how M.A.F Cloud shows you the real status of each allocation before players try to join.
Why Game Server Networking Is Different From Web Apps
Web applications run over HTTP, which is always TCP. That simplicity lets web frameworks abstract away most network details from developers. Game servers are different because they typically need both connection-oriented traffic (TCP) and connectionless traffic (UDP).
**TCP (Transmission Control Protocol)** handles data that must arrive intact and in order. Examples include chat messages, inventory updates, world saves, and admin commands. If a TCP packet gets lost, it gets retransmitted until it arrives. This reliability comes at a cost: slower throughput and more overhead.
**UDP (User Datagram Protocol)** sacrifices reliability for speed. Packets may be dropped or arrive out of order, but the priority is low latency. Player positions, movement updates, and voice chat all use UDP because waiting for missing packets would make gameplay feel broken.
Minecraft Java Edition uses TCP on the main server port for critical gameplay data and UDP on a separate port for Bedrock crossplay when Geyser is installed. Other games vary widely: Factorio leans heavily on TCP, ARK requires specific UDP ranges, and many modern titles need BOTH protocols on the same port number.
This dual-protocol requirement is why game server panels need explicit protocol selection, while web hosting platforms can assume TCP everywhere.
Docker Networking Basics Every Host Needs
Docker containers run in isolated network namespaces by default. A container cannot see your host's interfaces unless you explicitly map them. Here is what matters for game servers:
**Host networking.** The container shares your host's network stack directly. Performance is best because there is no NAT layer, but you lose isolation and multiple containers cannot bind the same port simultaneously. Most game hosting panels avoid this mode due to collision risks.
**Bridge networking (default).** Each container gets its own virtual interface connected to a bridge network. You map host ports to container ports using -p flags or docker-compose. Traffic flows through the host's IP and gets forwarded into the container. This is the standard mode for game servers because it provides clean port mapping and basic isolation.
**None networking.** The container has no network access except localhost. Useful for backup containers or database-only tasks that should not expose any ports publicly.
**Overlay networking.** Multi-host networks for clustering across machines. Advanced feature rarely needed for typical self-hosted setups where all services run on one VPS.
For practical game hosting, you operate in bridge mode with explicit port mappings. Your game process inside the container listens on port J (the internal port). Docker forwards external requests arriving at host port P to container port J via the command docker run -p P:J. When deploying a Minecraft server on port 25565, the container listens on 25565 and you map your chosen host port (e.g. 12345) to match.
The key insight: the port your players connect to is the host port, not the container internal port. Panel software like M.A.F Cloud handles this mapping invisibly when you create a server.
Understanding Port Protocols and BOTH Mode
Modern panels including M.A.F Cloud give you three choices for each allocation: TCP only, UDP only, or BOTH. Selecting the wrong one breaks connectivity half the time.
**TCP only** means only transmission control protocol traffic is routed to your server. If you select TCP for a Minecraft server, players connecting over TCP work fine, but Bedrock users via Geyser cannot reach you because Bedrock runs exclusively over UDP.
**UDP only** routes user datagram protocol traffic. Suitable for servers like CS:GO or Valorant that do not require TCP handshakes. However, Minecraft fails entirely if you pick UDP only because the core server handshake and chunk transfers fail without TCP.
**BOTH** enables bidirectional forwarding for TCP and UDP on the same port number. In M.A.F Cloud, when you deploy a Paper server, the allocation automatically sets protocol=BOTH so both Java (TCP) and Bedrock (UDP) traffic reaches the same container port. You do not need manual configuration beyond selecting BOTH as the allocation type.
Game-specific recommendations:
**Minecraft Paper/Fabric/Forge**: ALWAYS BOTH. Main port for Java (TCP), Bedrock via Geyser on same port (UDP)
**CS:GO/DragonBall Z**: Both possible, but typically TCP primarily with UDP subcomponents. Check docs.
**Rust**: TCP + UDP on same port range. Use BOTH.
**ARK**: Large UDP port ranges plus TCP. Configure allocations carefully, often requiring multiple entries.
**Terraria**: TCP primarily. UDP optional for player discovery.
Never assume TCP. Always verify with official documentation or testing tools before setting up production servers.
What Are Allocations in Self-Hosted Panels?
In traditional shared hosting, every service binds a well-known port and the host routes traffic based on domain names or subdomains. Game hosting is different because you run multiple identical server instances (Paper, Rust, etc.) on the same physical machine. Port collisions are inevitable.
**Allocations** are unique port assignments for each deployed server instance. The panel selects a free port on your VPS and assigns it to your server container. Players connect to that allocation port, not to a fixed number like 25565.
**M.A.F Cloud allocations work like this:**
1. You click Create Server in the dashboard and choose Minecraft > Paper version 1.21.4
2. The system scans your VPS and finds an available port range (typically random high-numbered ports above 30000)
3. The allocation record stores: the assigned port, protocol (BOTH), and whether the port passes a live probe test
4. When the container starts, M.A.F Cloud generates the exact docker run command with -p <allocation_port>:25565 mapping
5. The panel displays the connection string: your_vps_ip:23456 so players know what to enter in their launcher
The beauty of allocations is automation. You never run netstat to find free ports, and you never accidentally deploy two Rust servers on port 28015. Every new deployment gets a fresh allocation guaranteed to be conflict-free.
Live Port Probes — Real Connectivity Verification
An allocated port does not mean much if something blocks it after creation. Common blockers include cloud provider firewalls, VPS iptables rules, Docker bridge misconfiguration, or security groups in providers like DigitalOcean or Hetzner.
M.A.F Cloud includes a live port probe that runs immediately after allocation assignment. The probe attempts to establish connections to your allocation port using both TCP and UDP (when protocol=BOTH). Success returns green; failure returns red with diagnostic details.
**What the probe checks:**
Is the allocation port open and accepting TCP SYN packets?
Does UDP traffic reach the container namespace even though UDP is connectionless?
Is the firewall chain FORWARD policy allowing traffic between bridge interfaces?
Can you actually reach the game port from outside the VPS?
If the probe fails, common fixes include:
Adjusting security group rules in your VPS provider dashboard (DigitalOcean firewalls are mandatory to configure manually)
Running sudo ufw allow <port_number>/tcp and sudo ufw allow <port_number>/udp on Ubuntu/Debian
Verifying Docker bridge network exists and is not disabled (docker network ls shows bridge and mafcloud_default networks)
Checking if SELinux is enforcing and blocking container access (sudo setenforce 0 tests temporarily)
After any fix, return to the server list in M.A.F Cloud and refresh the allocations tab. The probe re-runs automatically and should show green for successful deployments.
WebSocket Console — Watch Network Events in Real Time
Traditional SSH access shows you terminal output from the server process itself. WebSocket consoles add another dimension by showing network-level events live. In M.A.F Cloud, the console streams both stdout/stderr from the game process AND network diagnostics like:
Connection accepted from client IP address
Protocol detected (TCP vs UDP packet received)
Bandwidth usage per second (packets sent/received)
Allocation port state changes (up/down/maintenance)
Crash recovery triggered by network timeout or memory spike
This visibility helps you diagnose issues faster than SSH logs alone. For example, if players report slow login times, the console shows the exact moment their TCP handshake started and whether your VPS responded within acceptable latency windows.
Unlike SSH tunnels that buffer output, WebSocket connections push data instantly. You see startup logs the millisecond they appear, and crash alerts before the process fully exits. Combined with automatic restart policies, this means minimum downtime during incidents.
Troubleshooting Common Game Server Network Issues
**Problem: Players receive connection refused errors**
Diagnosis steps: First confirm the allocation probe is green in M.A.F Cloud. Then test locally using telnet your_vps_ip allocation_port or nc -vz your_vps_ip allocation_port. If local succeeds but remote fails, check cloud provider firewall rules. If local also fails, the server container probably did not start successfully.
**Problem: High latency but stable connection**
Diagnosis steps: Verify the VPS region matches your players geographic location. Singapore serves Southeast Asia best, Frankfurt serves Europe, Iowa serves US East Coast. Latency from Malaysia to Iowa exceeds 200ms round-trip regardless of perfect networking setup. Also check if UDP fragmentation causes packet loss on certain routers.
**Problem: One protocol works but not BOTH**
Diagnosis steps: Inspect the allocation protocol setting. For Minecraft with Geyser enabled, BOTH is mandatory. TCP-only allows Java clients but drops Bedrock entirely. Review docker ps output to confirm port mapping syntax matches what you expect: CONTAINER_ID PORTS shows 0.0.0.0:23456->25565/tcp,23456/udp confirming dual protocol binding.
**Problem: Firewall blocks allocation port after initial success**
Diagnosis steps: Run sudo iptables -L -n -v to view current filter chains. Look for DROP or REJECT rules affecting INPUT or FORWARD chains containing your allocation port. Add permanent exceptions with ufw: sudo ufw allow 23456/tcp && sudo ufw allow 23456/udp. Restart firewall: sudo systemctl restart ufw.
**Problem: Container restarts repeatedly with allocation failures**
Diagnosis steps: Check server health status in M.A.F Cloud dashboard. Persistent restarts indicate either insufficient RAM or crashed game process. Inspect console output for OutOfMemory errors, plugin conflicts, or corrupted world files. Increase memory allocation from dashboard settings, then trigger rebuild.
Every network issue traces back to one of these five categories: wrong port, wrong protocol, blocked traffic, bad region, or crashed container. Work through the checklist systematically rather than guessing.
Practical Example: Deploying Minecraft with Proper Networking
Here is the exact flow in M.A.F Cloud that guarantees working network setup:
1. Create account at mafcloud.my.id and log into dashboard
2. Add Node and run the one-line agent installer via SSH (curl -fsSL https://cexi.my.id/agent-install.sh | sudo MAFCLOUD_TOKEN=your_token MAFCLOUD_API=https://cexi.my.id bash)
3. Click Create Server, choose Minecraft, Paper, version 1.21.4
4. Set RAM to 2GB or higher depending on expected player count
5. The system auto-generates an allocation with protocol=BOTH and runs a live port probe
6. Wait for green indicator in allocations tab
7. Copy connection string displayed next to the server card
8. Distribute to players along with your VPS public IP
No manual firewall configuration required if your VPS provider supports automated rule management. If DigitalOcean firewall is enabled, the panel instructs you to add a simple inbound rule allowing UDP and TCP on the allocated port. One-time action, permanent result.
Conclusion: Networking Done Right Once
Understanding TCP, UDP, allocations, and port probes transforms your ability to deploy reliable game servers. You stop chasing phantom connection failures and start building infrastructure that just works. M.A.F Cloud handles the hard parts automatically while giving you full visibility into every network event through WebSocket console and allocation probes.
The investment here is ten minutes learning concepts that prevent hours of troubleshooting later. With correct protocol selection, proper port mapping, and verified probes, your servers stay online for friends and communities who depend on consistent uptime.