The Port Checker indicates all ports are closed yet users are successfully connecting.
The Port Checker indicates all ports are closed yet users are successfully connecting.
I manage a server for a game titled 7 Days to Die. The standard port is 26900. The port checker indicates this port is closed, even though: A) it appears open in Windows Defender Firewall, B) it shows as open in AVG Firewall, and C) it is forwarded through my router. Users can still access the server without issues, and I received a Discord link from a server mod that shared the game chat in the designated channel. This behavior is normal. Additionally, I’m attempting to host another server, SCUM, on port 7779. Despite having it forwarded and enabled on all systems, the port checker still reports it as closed. It also flags HTTP, mail (port 110), FTP (port 21) as closed, and every other port as closed. I have a VPN installed, but it isn’t paid or active, so it’s not running. I always disable security features temporarily to test, but it doesn’t affect the result. The port checker consistently says all my ports are shut down. Also, my connection is wired with a 500MBPS link.
Please share:
- The laptop model (if any)
- GIGABYTE G6KF (SKU RC56KF)
- Router model
- Detailed specs of your PC (if applicable):
- Intel 13th Gen Core i7 i3620H 2400 MHZ 10 Cores, 16 Logical Processor, 32GB RAM, RTX 4060
- Motherboard make and model
- Power supply details
- USB or PCI Wi-Fi adapter
- Operating system and driver version
- ISP and connection type
- Number of devices connected to the router (tablets, phones, laptops, PCs)
- Any error messages from your ISP or Windows
Starry supports both wireless and wired connections, with a 500MBPS link.
You should also mention whether you have a NAS or regular server connected, if a Wi-Fi router is on the network, and whether you’re using an internal LAN connection (switches, ports, etc.).
I have tested restarting the router after changes, restarting my laptop, relaunching the server.exe, and rechecking ports. All attempts to connect have succeeded.
Report any issues you receive from your ISP or Windows.
Never share your public IP address on forums or any platform, as it might aid malicious activities. The moderators are likely to remove that entry. The real issue you're dealing with is probably the SCUM server, isn't it? The 7D2D port serves as an extra clue?
The test site can only connect to the port correctly when the service is active on your machine, so the first step is to confirm whether SCUM and 7D2D are running.
Next, verify if Windows displays activity on those ports. Launch a command prompt and execute "netstat -na", then paste the output into Notepad and look for 26900. You should see entries like:
TCP 192.168.1.101:26900 0.0.0.0:0 LISTENING
TCP 127.0.0.1:26900 0.0.0.0:0 LISTENING
TCP 0.0.0.0:26900 0.0.0.0:0 LISTENING
Check the results carefully; these indicate whether the port is open or not.
Repeat this process with your computer's actual IP and the SCUM server port 7779. (I noticed various port lists for SCUM, so it’s likely you’re targeting the correct one. If not all ports are open, it could impact connectivity.)
Then, attempt to establish a connection using the command line. On your device, run "telnet 127.0.0.1 26900" to test the 7D2D port. It should briefly connect and then either proceed or prompt for input. If it fails with "could not open connection," it suggests a firewall is blocking it.
Check if this issue persists on another networked computer, which would confirm whether the problem lies with your local setup or the firewall.
If everything functions properly, you can be confident your system allows communication and assesses firewall behavior.
Having access to another machine could let you replicate the tests from there, though that’s essentially what the test sites are doing. You might also review router logs to see if incoming connections are being forwarded or blocked during attempts.
There are three essential conditions that need to be met for the port checker to operate properly.
First, you should possess a public IP address and ensure you are testing the correct one.
Second, you must have the appropriate port forwarding configurations in place.
Third, there needs to be an active program listening on that port and responding accurately.
The third point is often the source of confusion. Turning off your machine will not work if it isn’t responding, nor does it matter if no program is running on that specific port. Certain applications are designed to respond only to specific ports for validated remote IP addresses. This behavior differs significantly across different software.
A simple initial check involves using the DMZ feature in your router to forward all ports. While this isn’t ideal for long-term use, it can quickly reveal issues related to port forwarding rules. Many routers have complex and confusing settings for this purpose.
If the DMZ still shows no activity, proceed by checking if any traffic is being received. Use tools like Wireshark or another capture utility. Ideally, only open a single browser tab to the testing site. This will help you gather data efficiently without overwhelming your analysis.
Your objective is to confirm whether packets are actually reaching your device. This confirms that both condition one and two are satisfied. Then assess whether your machine is properly responding and if any response is being lost or ignored.
Wireshark captures can be performed before the firewall, though you mentioned it’s permitted. Alternatively, you could briefly disable the firewall to test further.