Port Forwarding Check (TCP/UDP) — Quick Guide
If a forwarded port looks closed or filtered, it does **not** always mean the port mapping is broken.
In many cases, the mapping is working, but:
- no service is listening on that port
- the server firewall is blocking it
- the test is using the wrong protocol (TCP vs UDP)
> The port numbers below are just examples (like 25091–25099).
> Please replace them with **your own assigned ports**.
---
## 1) Check if your server is listening on the port
Run this on your server:
ss -lntup | grep <your-port>
Examples:
- `ss -lntup | grep 25091`
- `ss -lntup | grep -E '25091|25092|25093'`
If nothing is listening, the port can look closed even if forwarding is correct.
---
## 2) Check whether traffic is reaching your server (best proof)
Run this on your server (as root), and keep it running while you test from outside:
tcpdump -ni any 'port <your-port>'
Examples:
- `tcpdump -ni any 'port 25091'`
- `tcpdump -ni any 'port 25091 or port 25092 or port 25093'`
How to read it:
- **If you see incoming packets** from the remote IP → forwarding is working
- **If you see nothing at all** → likely a forwarding/NAT/router issue
This works for **both TCP and UDP**.
---
## 3) Test from an external network (important)
Please test from a different network (for example mobile hotspot, another office, or a VPS).
Testing from the same LAN may give misleading results.
### TCP test
- Single port:
`nc -vz your-domain.com <your-port>`
- Port range:
`nmap -Pn -p <start-port>-<end-port> your-domain.com`
### UDP test
- Single port:
`nc -u -vz your-domain.com <your-port>`
Note: UDP is connectionless, so client-side results can be unclear.
For UDP, **server-side tcpdump** is usually the most reliable proof.
---
## 4) Optional: Run a temporary test service (to confirm quickly)
If you are not sure your app is listening correctly, start a temporary listener on the server.
### TCP (simple)
`nc -lvkp <your-port>`
Then test from outside:
`nc -vz your-domain.com <your-port>`
### TCP (returns a clear response)
`sudo socat TCP-LISTEN:<your-port>,reuseaddr,fork SYSTEM:"echo 'port <your-port> OK'"`
Then test from outside:
`nc your-domain.com <your-port>`
If you receive a reply like `port 25091 OK`, the TCP path is working.
### UDP (simple)
`nc -u -lvkp <your-port>`
Then test from outside:
`echo test | nc -u -w1 your-domain.com <your-port>`
Check the server terminal or tcpdump to confirm the UDP packet arrived.
---
## How to tell where the issue is
### A) Packets arrive at the server, but the port still “fails”
This usually means the problem is on the **server side**:
- no service listening
- service listening on the wrong IP (for example `127.0.0.1` only)
- server firewall blocking it
- protocol mismatch (testing TCP while service uses UDP, or the opposite)
### B) No packets arrive at the server
This usually means the problem is on the **forwarding/network side**:
- wrong port forwarding rule
- wrong internal server IP
- router/firewall policy
- double NAT environment
---
## If you need support, please send us
To help us check quickly, please include:
- your affected port number(s)
- the exact test time (with timezone)
- your test command and output (`nc` / `nmap`)
- server output of `ss -lntup`
- a few lines of `tcpdump` output
---
## Final note
A port showing as “closed” or “filtered” does **not** automatically mean forwarding is broken.
The fastest way to confirm is:
1. Test from an external network
2. Run `tcpdump` on the server
3. Check whether packets arrive
If packets arrive, the forwarding path is working for that protocol (**TCP/UDP**).
