NAT Port Forwarding Not Working? Check These Layers

Troubleshoot NAT forwarding from the application outward: process, listening address, guest firewall, mapping and external client. Changing several layers at once makes the original cause harder to identify.

1. Verify the guest service

Check the application's status and logs. Use ss -lntup to inspect sockets. A service bound only to 127.0.0.1 generally cannot receive traffic forwarded to the guest interface. For HTTP, test the intended local address and port before testing the Internet path.

2. Verify protocol and destination

Match TCP to TCP or UDP to UDP. Confirm the private destination port in the panel and the port the application actually uses. For a container, account for Docker's published guest port as well as the container's internal port.

Inspect the guest firewall. For ordinary destination NAT, it usually sees the private destination port, not the public mapped number. Do not disable all filtering as a permanent fix.

3. Test from outside

Use the actual public address and assigned public port from an independent network. Do not rely only on a guest-to-own-public-address test, which can depend on NAT loopback. For UDP, use the real application because a silent arbitrary probe is inconclusive.

4. Isolate application-specific behavior

Some protocols advertise their own addresses or negotiate extra ports. A single successful connection may not cover the complete session. Check application documentation for NAT support.

When contacting support, include instance ID, protocol, mapped ports, timestamp and a redacted error. Never include a private key or password. See TCP mappings, UDP mappings and UFW rules.