If a forwarded port appears closed or filtered, it does not necessarily mean that port forwarding is not working.

Common causes include:

• No service is listening on the port
• The server firewall is blocking the connection
• The wrong protocol is being tested, such as TCP instead of UDP

Important: The port numbers below are examples only. Replace them with your own assigned ports.

1. Check Whether the Port Is Listening

Run the following command on your server:

ss -lntup | grep <PORT>

Examples:

ss -lntup | grep 25091
ss -lntup | grep -E '25091|25092|25093'

If no result is returned, no service is currently listening on that port. The port may appear closed even when port forwarding is configured correctly.

2. Check Whether Traffic Reaches the Server

Run the following command as root and keep it running while testing the port from another network:

tcpdump -ni any 'port <PORT>'

Examples:

tcpdump -ni any 'port 25091'
tcpdump -ni any 'port 25091 or port 25092 or port 25093'

• Packets are visible: Port forwarding is working, and the issue is likely inside the server.
• No packets are visible: The forwarding rule or network configuration may need to be checked.

This test works for both TCP and UDP traffic.

3. Test from an External Network

Test from a different network, such as a mobile hotspot, another office, or another VPS. Testing from the same local network may produce inaccurate results.

TCP Test

Test a single port:

nc -vz <PUBLIC_HOST_OR_DOMAIN> <PORT>

Test a port range:

nmap -Pn -p <START_PORT>-<END_PORT> <PUBLIC_HOST_OR_DOMAIN>

UDP Test

nc -u -vz <PUBLIC_HOST_OR_DOMAIN> <PORT>

UDP is connectionless, so the result shown by the client may not always be clear. For UDP testing, checking incoming packets with tcpdump on the server is usually more reliable.

4. Run a Temporary Test Service

If you are unsure whether your application is listening correctly, you can temporarily open a test listener.

Simple TCP Listener

Run on the server:

nc -lvkp <PORT>

Test from an external network:

nc -vz <PUBLIC_HOST_OR_DOMAIN> <PORT>

TCP Listener with a Response

Run on the server:

socat TCP-LISTEN:<PORT>,reuseaddr,fork SYSTEM:"echo 'port <PORT> OK'"

Test from an external network:

nc <PUBLIC_HOST_OR_DOMAIN> <PORT>

If you receive a response such as port 25091 OK, the TCP connection is working.

Simple UDP Listener

Run on the server:

nc -u -lvkp <PORT>

Test from an external network:

echo test | nc -u -w1 <PUBLIC_HOST_OR_DOMAIN> <PORT>

Check the server terminal or tcpdump output to confirm that the UDP packet arrived.

How to Identify the Problem

Packets Reach the Server, but the Connection Still Fails

The issue is usually on the server side:

• No service is listening on the port
• The service is listening only on 127.0.0.1
• The server firewall is blocking the connection
• The service and test are using different protocols

No Packets Reach the Server

The issue may be related to the forwarding or network configuration:

• The wrong public port is being tested
• The forwarding rule is incorrect
• The internal server IP is incorrect
• A router or firewall policy is blocking the traffic
• The connection is behind multiple layers of NAT

Information Required for Support

If you need assistance, please provide:

• The affected port number or port range
• The exact test time and timezone
• The test command and complete output
• The output of ss -lntup
• A few relevant lines from the tcpdump output

Final Note

A port appearing closed or filtered does not automatically mean that port forwarding is not working.

The quickest way to confirm the connection is:

1. Test from an external network
2. Run tcpdump on the server
3. Check whether incoming packets are visible

If packets reach the server, the forwarding path is working for the tested protocol.