How to Check if a Port Is Blocked: Windows, macOS, Linux

Quick answer: To check if a port is blocked, test the exact destination, protocol, port and direction from the affected device. Use Test-NetConnection for TCP on Windows or the installed nc variant on macOS/Linux. A completed connection confirms that attempt; a timeout or refusal does not identify a firewall. Check DNS and the listener, then correlate a controlled attempt with applicable rules and logs. For a proxy, test gateway TCP reachability separately from authentication and destination access.

This guide covers client-to-server checks, local listeners, firewall evidence and Socks5.IO endpoint troubleshooting. All tests should target a device or service you own or are authorized to diagnose. You do not need to disable security software, scan a public network or open unsolicited inbound access to test an outbound proxy connection.

First define what “blocked” means

A port number is meaningful only alongside its destination address, transport protocol and direction. TCP 443 and UDP 443 are different tests. An open listener on your laptop says nothing by itself about an outbound connection to a provider’s gateway.

Record these details before changing anything:

For a remote proxy, use the endpoint details actually issued by the provider. Port 1080 is a familiar SOCKS example, not a universal Socks5.IO gateway port. Do not substitute a remembered default for the generated configuration.

How to check if the port is open on Windows

1. Test the destination from the affected client

In PowerShell, enter the approved destination and port:

$targetHost = Read-Host 'Approved destination hostname or IP'
$targetPort = [int](Read-Host 'Destination TCP port')
Test-NetConnection -ComputerName $targetHost -Port $targetPort -InformationLevel Detailed

Record TcpTestSucceeded, RemoteAddress, RemotePort, SourceAddress and InterfaceAlias. Microsoft documents these diagnostic capabilities in Test-NetConnection.

• True: a TCP connection completed for that address and attempt. It does not prove the correct service, valid credentials or successful HTTPS traffic.
• False: connection failed. Inspect the failure context before blaming a firewall.
• Ping failure with TCP success: ICMP and TCP can be treated differently; a ping result does not override the TCP result.

Check the displayed RemoteAddress. A hostname may resolve to several addresses, and an IPv4 result does not establish IPv6 reachability. If you repeat against a resolved literal IP, keep the same service and route; a bare-IP TCP probe does not replace hostname-based TLS or application testing.

2. Check whether your own server is listening

Run the next command on the server hosting the service, not automatically on the client:

$servicePort = [int](Read-Host 'Local service TCP port')
Get-NetTCPConnection -State Listen -LocalPort $servicePort |
    Select-Object LocalAddress, LocalPort, OwningProcess

Use the returned process ID to inspect the process:

Get-Process -Id 1234

Replace 1234 with the observed PID. Microsoft’s Get-NetTCPConnection documentation covers these local socket properties. Inspection may require appropriate permissions.

A listener bound only to 127.0.0.1 cannot accept direct connections to the machine’s LAN address. A wildcard or IPv6 bind needs separate address-family verification. No matching listener may mean the service is stopped, bound elsewhere or not visible to your account—not that a firewall closed a functioning application.

3. Try a safe local positive/negative control

This optional exercise creates a temporary loopback-only TCP listener on an OS-selected port, checks it, stops it, then checks again. It changes no firewall rules and exposes no LAN service:

$demoListener = [System.Net.Sockets.TcpListener]::new(
    [System.Net.IPAddress]::Loopback, 0
)
try {
    $demoListener.Start()
    $demoPort = $demoListener.LocalEndpoint.Port
    Test-NetConnection 127.0.0.1 -Port $demoPort -InformationLevel Quiet
    $demoListener.Stop()
    Test-NetConnection 127.0.0.1 -Port $demoPort -InformationLevel Quiet
}
finally {
    $demoListener.Stop()
}

Normally the two results are True and False, assuming no other process reuses the port. The contrast demonstrates a missing listener without deliberately blocking traffic. It does not simulate a network firewall, validate a proxy or establish Internet reachability. A loopback test can behave differently from traffic on a real interface.

Telnet can also attempt a TCP connection if installed, but a blank screen or disconnected session is weak protocol evidence. Installing it is unnecessary for these PowerShell checks, and Telnet does not test UDP or perform a SOCKS5 authentication exchange.

How do you check a TCP port on macOS or Linux?

Use the affected client and one authorized destination. With common Linux OpenBSD-style netcat installations:

target_host='approved-host.example.invalid'
target_port='443'
nc -vz -w 5 "$target_host" "$target_port"

Replace the deliberately non-working .invalid hostname and sample port. On the macOS-provided nc, a bounded connection attempt can use:

target_host='approved-host.example.invalid'
target_port='443'
nc -vz -G 5 -w 5 "$target_host" "$target_port"

Netcat variants differ. Check man nc locally; do not assume every GNU, BusyBox, OpenBSD or macOS build accepts identical flags. The OpenBSD nc manual documents its implementation. For this TCP probe, -z avoids sending application data and -v reports diagnostic output; neither authenticates a proxy.

On a Linux server you control, inspect local TCP listeners with:

sudo ss -ltnp

Find the exact local address, port and process. The ss manual distinguishes socket-listing options; process details may require privilege. On a Mac hosting the service, a common alternative is:

sudo lsof -nP -iTCP:443 -sTCP:LISTEN

Replace 443 with the actual local port. Reading a listening socket is not proof that a remote packet can reach it.

When is Nmap useful?

If authorized and installed, a single-port TCP connect check gives another diagnostic view:

nmap -sT -Pn -p 443 approved-host.example.invalid

Use the real approved target and port. Nmap’s port-state documentation distinguishes:

These states describe the scanner’s view from one path and time, not permanent properties. A reset can also be generated by an intermediary, and filtered does not identify a particular firewall. Do not broaden this into an unauthorized range scan.

How to Check if a Firewall Is Blocking a Port on Windows

Use connection tests to locate the symptom, then inspect applicable policy and matching packet evidence. A port-only search through rules is insufficient: direction, profiles, addresses, application, service and policy origin can all matter.

1. Inspect the active network category and profile settings

These are read-only commands:

Get-NetConnectionProfile |
    Select-Object InterfaceAlias, NetworkCategory, IPv4Connectivity, IPv6Connectivity

Get-NetFirewallProfile -PolicyStore ActiveStore |
    Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundAction,
                  LogBlocked, LogAllowed, LogFileName

Get-NetFirewallProfile reports profile configuration. Compare it with the interface used by the failing test. A profile set to allow outbound traffic does not mean no specific blocking rule applies; third-party endpoint controls and centrally managed policies may also affect traffic.

2. Inspect enabled blocking rules and their port filters

For example, list candidate rules from the effective policy store:

Get-NetFirewallRule -PolicyStore ActiveStore -Enabled True -Action Block |
    ForEach-Object {
        $candidateRule = $_
        $portFilter = $candidateRule | Get-NetFirewallPortFilter
        [pscustomobject]@{
            Name       = $candidateRule.Name
            DisplayName = $candidateRule.DisplayName
            Direction  = $candidateRule.Direction
            Profile    = $candidateRule.Profile
            Protocol   = $portFilter.Protocol
            LocalPort  = $portFilter.LocalPort -join ','
            RemotePort = $portFilter.RemotePort -join ','
        }
    }

For a selected rule, replace RULE-NAME with its observed Name:

$candidateRule = Get-NetFirewallRule -PolicyStore ActiveStore -Name 'RULE-NAME'
$candidateRule | Get-NetFirewallAddressFilter
$candidateRule | Get-NetFirewallApplicationFilter
$candidateRule | Get-NetFirewallServiceFilter

The Get-NetFirewallRule documentation explains rules and associated filters. This candidate list is not an automatic allow/block evaluator; it omits default-deny cases and other control layers.

For an outbound proxy connection, the gateway port is normally the remote destination port. For an inbound service, the service port is normally local. Account for Any, ranges, the applicable profile and full filter scope. An unrelated rule mentioning the same number is not proof of a match. The graphical alternative is Windows Defender Firewall with Advanced Security: inspect the relevant Inbound or Outbound rule and its complete properties, without changing it merely to test a theory.

3. Correlate a fresh attempt with dropped-packet logs

Read the LogFileName for the applicable profile rather than assuming every installation uses the same location. If logging is already enabled and you have access:

$firewallLog = Read-Host 'Existing log path from the applicable profile'
Get-Content -LiteralPath $firewallLog -Tail 100

If the path contains environment variables, expand them deliberately before reading it. Do not run or import log contents as commands.

Make one controlled attempt and compare its timestamp, protocol, source address/port and destination address/port with a matching DROP entry. Read the log’s field header and time-format information; convert timezones when correlating records. Keep the raw evidence privately because logs can expose network details.

No matching entry does not prove that a firewall allowed the connection. Logging may be disabled, the wrong profile or time window may be inspected, or the drop may occur elsewhere. If logging is not enabled, ask the authorized administrator to configure it under the organization’s policy; Microsoft’s Windows Firewall logging guide describes supported configuration methods. This tutorial does not switch logging, rules or firewall state automatically.

How to Check Whether a Firewall Is Blocking a Port on macOS, Linux, or the Network Path

On an Ubuntu server using UFW, read its status and managed rules:

sudo ufw status verbose
sudo ufw status numbered

The official Ubuntu firewall guide covers UFW. Inactive UFW does not establish that every nftables/iptables rule, cloud security group or network firewall is absent. On a host using nftables, an authorized administrator can inspect sudo nft list ruleset; do not flush rules to make a test pass.

For a Mac-hosted service, review its bind address and inbound application permissions. Apple’s firewall guidance concerns incoming connections; it is not a universal explanation for every outbound failure. Managed network extensions, VPN routes and upstream controls are separate checks.

To investigate an upstream firewall or possible ISP issue, keep the destination IP, port, transport and test window comparable. Where permitted, compare another approved client or network and involve the server owner. A different network succeeding narrows the investigation but does not identify the ISP as the blocker: DNS, IPv6 selection, VPN routing and endpoint policy may also differ.

Stronger attribution comes from matching firewall logs or captures at known points. A client SYN with no observed reply shows an unanswered attempt at that capture point, not the location or reason for loss. Correlate server-side receipt, return traffic and intermediary logs before escalating a specific blocking claim.

Can an online port checker prove an outbound proxy port works?

Usually not. An external checker tests reachability from its own server toward the supplied public address. That is different from your laptop connecting outbound to a provider’s proxy gateway.

For a self-hosted inbound service, you also need the correct listener, host policy, public addressing and any required NAT mapping. Carrier-grade NAT or multiple routers can prevent unsolicited inbound reachability without preventing ordinary outbound connections. A router’s port-forward rule cannot start a stopped service or automatically create a public address.

A desktop proxy client normally does not need an inbound router forward to use Socks5.IO. Do not expose a laptop port or a proxy administration panel merely because an online checker reports closed. Test the actual gateway from the affected client instead.

Troubleshoot a Socks5.IO connection in layers

Keep the two network legs distinct:

Your client → issued proxy gateway:port → permitted destination:port

The first leg must work before the proxy can help with the second. Socks5.IO dynamic residential proxies are one routing option, but changing the exit IP category does not repair a blocked client-to-gateway connection.

1. Confirm issued fields, DNS and gateway TCP reachability

For a full initial configuration, follow the residential proxy setup walkthrough, then obtain the supported host, port, protocol and proxy credentials for your active product. Do not use your dashboard login or invent an alternative port, including 443, unless the provider actually issues it and the network administrator permits it.

On Windows, reuse the Test-NetConnection example with the issued gateway. If name resolution fails, repair the gateway DNS configuration first. If TCP fails, preserve the resolved address, source interface and time before investigating network policy. A different proxy IP type cannot repair a connection that never reaches the gateway.

2. Test SOCKS5 authentication and an HTTPS request

A successful gateway TCP test is only the first step. Check SOCKS5 versus HTTP proxy compatibility before choosing the client configuration: a TCP connection does not identify the protocol running on the port. This optional Python client checks the issued SOCKS5 credentials without putting the password in command history. Install requests[socks] in an isolated environment, then save the full block as check_proxy.py:

python -m venv .venv
.\.venv\Scripts\python.exe -m pip install "requests[socks]>=2.32,<3"

from getpass import getpass
from urllib.parse import quote
import ipaddress
import re
import requests


def check_proxy():
    host = input("Issued proxy host: ").strip()
    port = int(input("Issued proxy port: "))
    if not re.fullmatch(r"[A-Za-z0-9.-]+", host) or not 1 <= port <= 65535:
        raise ValueError("Check issued host and port")
    user = quote(input("Issued proxy username: "), safe="")
    password = quote(getpass("Issued proxy password: "), safe="")
    proxy = f"socks5h://{user}:{password}@{host}:{port}"
    with requests.Session() as session:
        session.trust_env = False
        session.proxies.update(http=proxy, https=proxy)
        response = session.get("https://api.ipify.org?format=json", timeout=(5, 15),
                               allow_redirects=False)
        if response.status_code != 200:
            raise ValueError("Checker did not return HTTP 200")
        address = ipaddress.ip_address(response.json()["ip"])
        if not address.is_global:
            raise ValueError("Checker did not report a public address")
        print("Completed SOCKS5 + HTTPS checker request.")
        print("Observed exit IP (keep private):", address)


if __name__ == "__main__":
    try:
        check_proxy()
    except (ValueError, KeyError, OSError, requests.RequestException) as error:
        print("Check failed; exception category:", type(error).__name__)
        print("Review DNS, TCP, credentials, protocol and target checks separately.")
        raise SystemExit(1)

Run with the virtual environment’s interpreter:

.\.venv\Scripts\python.exe check_proxy.py

The checker is the public JSON endpoint documented by ipify, not a Socks5.IO API. Review its usage/privacy conditions before sending a request. The example keeps TLS verification on, uses proxy-side destination DNS with socks5h, avoids ambient proxy settings and makes no direct fallback or automatic retry. A custom CA must be configured explicitly where required. These timeouts are not a total task deadline.

If a ProxyError occurs, the safe exception category alone does not locate the failure; inspect its detailed cause privately without publishing secrets. Authentication failure, unsupported protocol and destination refusal can occur after the gateway port was reachable. A completed checker request proves that one SOCKS5/HTTPS path worked, not that every target, application or UDP flow works. Do not share the observed IP or credential-bearing proxy URL in screenshots.

3. Classify the result before changing configurations

For the final authorized target, repeat the application check in the actual collecting client under the same issued configuration. Do not treat a separate browser’s result as evidence that a script used the proxy. SOCKS5 is also not an encrypted VPN by itself; HTTPS protects the appropriate application connection, while any additional transport protection depends on configuration.

TCP and UDP need different conclusions

Test-NetConnection with -Port and the TCP examples above do not validate UDP. A UDP socket can exist locally even when remote datagrams receive no reply. Conversely, silence from a UDP probe can mean filtering, a silent application or an unsuitable request.

Use a protocol-aware, permitted request and correlate captures/logs for the actual UDP service. A UDP scan can report an ambiguous open|filtered state; do not convert that into a confirmed open result. For games, voice and QUIC, confirm application requirements and end-to-end client/provider support rather than assuming a successful TCP SOCKS test covers UDP relay behavior.

What should you do after finding the cause?

Use the smallest approved correction for the demonstrated problem: start or correctly bind the intended service, repair DNS, correct issued credentials, or ask the policy owner for the narrowly scoped access the application needs. Record the change and repeat the same test.

Do not turn off the firewall, allow all ports or create a public inbound forward as a generic fix. If a corporate rule prohibits a destination or proxy, request authorization; do not assume a proxy purchase permits evasion. Our proxy selection guide explains routing trade-offs after basic connectivity is understood, rather than offering a fix for every failed port test.

Example: TCP works but proxy authentication fails

Consider an authorized analyst whose script cannot reach an approved data source through an issued proxy. Test-NetConnection succeeds to the gateway, but the SOCKS client rejects authentication. The analyst checks the generated proxy username and discovers the script used the dashboard login.

The analyst corrects the credentials and repeats the same client-level request, without changing inbound policy or buying more IPs. This is a diagnostic scenario, not a customer incident or a measured Socks5.IO connection result.

Conclusion

Use a repeatable test record to connect each symptom with its relevant evidence: destination and transport, listening service, applicable policy, and the matching time window. Keep the investigation narrow and record the outcome of each approved correction.

For Socks5.IO, first confirm the issued gateway is reachable, then test supported proxy authentication and an HTTPS request from the real client. Keep inbound port forwarding, outbound access, TCP/UDP and destination policy separate, and apply only the correction supported by the evidence.