Game Server Running but Friends Cannot Join? Seven Checks in Order
Published and official references checked 2026-09-07 · SameOS operator
If you can join but a friend gets a timeout, start by separating the game process, the local network, the internet path and game login. Knowing the last successful boundary narrows the settings to change. This guide covers a personal Linux server running directly or in Docker bridge networking.
1. Record the destination and failure stage
Record the game and edition, client and server builds, entered address and port, test network and exact error. Mixing Java and Bedrock instructions can leave you changing the wrong settings. Record the minute of each attempt so it can be matched to server logs.
A name-resolution failure, a timeout and an explicit version or allowlist rejection occur at different stages. Appearing in a browser or server list does not prove a world can be joined.
2. Separate process startup from world readiness
An active service or Up container may still be loading its world. Look for readiness and repeated errors. If the process keeps restarting, solve startup before networking. The names minecraft and mc-server below are placeholders.
Use the first pair for systemd or the second pair for Docker. Redact addresses, player identifiers and credentials before posting logs publicly.
systemctl status minecraft --no-pager -l
journalctl -u minecraft -b -n 100 --no-pager
docker ps -a --filter name=mc-server
docker logs --since 10m --tail 100 mc-server3. Check transport and bind address
The usual Minecraft Java game connection defaults to TCP 25565; Palworld uses UDP 8211 as its default game-port example. Use your actual startup port if changed. A matching number with the wrong transport is a different endpoint.
For a directly hosted process, inspect listening sockets below. A loopback-only bind at 127.0.0.1 cannot directly accept another device. Binding to 0.0.0.0 accepts on IPv4 interfaces but says nothing about upstream firewalls. Check IPv6 and IPv4 reachability separately.
sudo ss -lntp
sudo ss -lnup4. Check Docker publication separately
In Docker bridge mode, distinguish the game port from the published host port. With 25566:25565/tcp, give players host port 25566. Host ss output alone does not fully describe Docker NAT publication; check docker port.
A mapping of 8211:8211 can default to TCP; confirm UDP for Palworld. Publishing only to localhost, such as 127.0.0.1:25565:25565, also prevents ordinary external joins. Review game ports separately from administrative RCON or REST endpoints.
docker port mc-server
docker inspect --format '{{json .HostConfig.PortBindings}}' mc-server5. Test LAN and internet paths independently
First join from another device on the same router using the server LAN address. If this fails, inspect the host firewall, Docker publication and guest-Wi-Fi isolation before internet forwarding.
Once LAN joining works, ask a friend on another network to use the public address. A public-address test from your own LAN may fail because of NAT loopback behavior. For external-only failures, check the forwarding destination and transport, cloud security rules and double-router topology.
A private or carrier-shared router WAN address can mean another NAT layer controls inbound access. Establish whether you control that router or whether your ISP provides an inbound-capable public address. Avoid masking the diagnosis with DMZ or a complete firewall shutdown.
6. Understand port-checker limits
A TCP checker cannot prove a UDP game connection works. Silence on UDP may not distinguish a listening endpoint from a blocked one. Use the real game client alongside server logs.
No log entry at the attempt time suggests checking the path, but games need not log every rejected request. An explicit version or allowlist rejection is stronger evidence that the request reached the game; resolve that message first.
7. Resolve game-level rejection and confirm recovery
After the path works, compare builds, required mods and loaders, passwords and allowlists. Change one setting and retest with the same client and address. If only one friend fails, compare their attempt with a successful player to isolate client or network differences.
Finish by joining the intended world from an external device, interacting and reconnecting. Record the working address, port and forwarding rule. Keep the server LAN address stable, for example with a DHCP reservation, so a reboot does not silently change the destination.
Verification scope and official references
This Linux operations guide was checked against the linked documentation and command options. Paths, service names, addresses and diagnostic scenarios are illustrative, not incident reports or performance measurements from SameOS game servers. We did not induce production failures or modify production saves. Confirm paths and behavior for your game build and deployment before applying changes.