A port-checking website says “closed,” yet the server is running. Before changing the firewall, establish whether the tool tested UDP at all. A TCP connection to port 8211 tells you nothing about a UDP socket with that same number. Even a genuine UDP probe can receive no reply from a working service when its payload is not a valid game request.
This guide uses Linux inspection commands and UDP 8211 as an example, not a universal game default. Substitute your installation's actual port. You need a running server, its configured game/query endpoints, administrator access and a test client outside the server's network. Install iproute2 and tcpdump through your distribution's package manager if absent; Nmap is optional on the external test machine.
Write down the endpoint and the test's question#
Record the destination address, IPv4 or IPv6, port, protocol and purpose. A game port, discovery/query port and RCON endpoint can use different protocols and permissions. Keep private administration private; opening RCON does not repair a game UDP path.
Ask separately: does the process own a socket, do external requests arrive, does the application answer, and can a player join? These questions require different evidence. A hostname also adds DNS: establish which address the client actually resolves before comparing traces.
The distinction has practical consequences. In a historical Unity forum case, the author eventually confirmed that a friend could connect while the TCP-only checker still reported a closed port. That case identifies a misleading test, not a reason to assume every connection failure is harmless.
Inspect the socket where the application runs#
For a native Linux process, inspect matching UDP sockets:
sudo ss -uanp 'sport = :8211'
The iproute2 socket manual documents the UDP, numeric, all-socket and process options. Compare the process and local address with the intended instance. An IPv4 loopback bind such as 127.0.0.1 cannot accept a direct remote connection; 0.0.0.0 is a wildcard bind, not the address to advertise to players. UDP UNCONN is normal for an unconnected datagram socket and is not a startup error.
No matching socket in the application's network namespace points you toward startup, a different port or a bind failure. Read the game log and readiness state before changing internet rules.
For containers, run inspection inside the application's namespace and inspect the published port separately. A host ss result alone is insufficient when forwarding uses NAT rather than a host proxy. Docker's port-publishing documentation distinguishes TCP and UDP mappings: publishing a number for TCP does not publish its UDP counterpart. A VM similarly adds its own network and firewall boundary.
Send a real request from outside the network#
Use a compatible game client or a query tool for the server's actual protocol from another internet connection. Record the attempt time and result. A query response validates that query endpoint; only a successful game join validates admission to the game.
If needed, run a single-port UDP scan from an external Linux machine you control against your own server:
sudo nmap -sU -Pn -p 8211 --reason 203.0.113.10
Replace 203.0.113.10 with the real IPv4 address; the example is reserved for documentation. -Pn skips the initial host-discovery decision, so a blocked ping does not prevent this scan.
Per Nmap's UDP reference, open|filtered means no decisive reply, not proven failure. An observed ICMP port-unreachable supports closed for that attempt, but investigate which device generated it. An open result is still not proof of a successful game session. Keep the scan narrow; thousands of timed-out probes add delay without answering the join question.
Observe packet direction during a timed join#
On the Linux host, capture a short summary while the external player attempts to connect:
sudo timeout 20s tcpdump -i any -nn -c 40 'udp port 8211'
This uses tcpdump's documented options to avoid name resolution and bound the capture. It stops after 40 packets or 20 seconds. A timeout exit status is expected if the time limit wins. No payload dump is requested. Packet summaries still contain addresses; share only relevant, redacted lines.
Interpret the trace with its capture location in mind:
| Observation during the known attempt | Next check |
|---|---|
| No matching inbound packet | Destination, external firewall, forwarding and upstream NAT; also verify the capture namespace/filter. |
| Inbound requests, no matching reply | Host filtering, socket binding, application readiness and a valid game payload. |
| Requests and replies leave the host | Return routing, upstream filtering, client network and game compatibility. |
| Player enters the intended world | Repeat the join after the final rule change and confirm the advertised endpoint. |
Seeing a packet on a host interface does not prove delivery to the application socket. With containers or translated ports, inspect the relevant namespace and translated endpoint too. Capture on any may show a packet at multiple interfaces; duplicate lines alone do not establish game retransmissions.
Change the boundary supported by the evidence#
Correct the wrong UDP mapping, bind address or specific firewall rule, then repeat the same external join. Avoid disabling every firewall or opening a wide port range: that removes useful isolation and can expose unrelated services.
If traffic never reaches a home server, compare router WAN and external IPv4 using the CGNAT guide. Keep the endpoint, test time, socket result and packet direction together when requesting help. Those observations support the next action far better than a screenshot containing only “port closed.”
