How to Fix Connection Refused on Your Server

Quick Answer (TL;DR)

If a port is unreachable on your dedicated server, the issue typically resides in one of three layers. To resolve it, check these components in order:

Service Listening State: Verify the application is running and properly bound to the correct network interface (ss -tulnp).
Host Firewall: Ensure your OS-level firewall (UFW, Firewalld, or iptables) is configured to allow the specific port and protocol.
Upstream Network Filtering: Check for external blocks, such as your hosting provider’s network ACLs, hardware firewalls, or routing issues.

Understanding Port Errors (Diagnostic Table)

Before executing commands, analyze the exact error message from your client (browser, terminal, or API). This helps narrow down the root cause.

Error Message	What It Means	Likely Causes
Connection Refused	The TCP connection attempt reached a destination, but was actively rejected (e.g., via a TCP RST packet).	Service is down, service bound to wrong IP, host firewall REJECT rule, or upstream device rejection.
Operation Timed Out	The connection attempt received no response within the expected timeframe.	Firewall DROP rule, routing issue, packet loss, or the remote server/interface is unresponsive.

Step 1: Verify the Application Status

A port cannot accept connections if the underlying application (e.g., Nginx, SSH, MySQL) is stopped or crashed. Check the systemd service status:

Bash

sudo systemctl status <service_name>

Look for Active: active (running). However, an active status does not guarantee the service is listening on the expected port. If the service shows as failed, investigate the recent logs to find the exact crash reason before proceeding:

Bash

sudo journalctl -u <service_name> -n 100 --no-pager

Step 2: Check Socket States and IP Binding

Your application might be running but configured to accept only local traffic. Use the ss utility (the modern, preferred alternative to netstat) to inspect listening sockets.

Bash

sudo ss -tulnp | grep ':<port_number>'

How to interpret the local address output:

127.0.0.1:<port> or [::1]:<port>: The service is bound to localhost. It will only accept connections from inside the server itself. Note: This is the correct and secure configuration for backend services like databases meant to be accessed only via a local reverse proxy.
0.0.0.0:<port> or *:<port>: The service is bound to all available IPv4 interfaces.
<Public_IP>:<port>: The service is explicitly bound to a specific network interface.

If external access is required but the service is bound to 127.0.0.1, you must update the application's configuration file to bind to the appropriate public-facing interface or 0.0.0.0.

Step 3: Inspect OS-Level Firewalls

If the service is running and properly bound, the host operating system's firewall may be blocking the connection. Ensure you only allow the specific protocol (TCP or UDP) your application requires.

For Ubuntu / Debian (UFW):

First, check the current active rules:

Bash

sudo ufw status verbose

If the required rule is missing, add it (e.g., for TCP port 80):

Bash

sudo ufw allow 80/tcp

For RHEL / AlmaLinux / Rocky Linux (Firewalld):

Check the active rules for your default zone:

Bash

sudo firewall-cmd --list-all

If the port is missing, add it permanently and reload the runtime configuration. (Note: If your public interface is assigned to a specific zone, append --zone=public to the command).

Bash

sudo firewall-cmd --add-port=80/tcp --permanent
sudo firewall-cmd --reload

Step 4: Docker Port Publishing (If Applicable)

If your application runs inside a Docker container, you must publish the internal container port to the host machine. Inspect the specific container's mappings:

Bash

docker port <container_name_or_id>

Security Warning: When you publish a port using -p 8080:80, Docker binds to 0.0.0.0 by default and actively modifies iptables, often bypassing UFW rules. If the service should not be publicly accessible, bind it specifically to localhost (-p 127.0.0.1:8080:80) or manage it through a dedicated Docker network.

Step 5: Verify Upstream Network Filtering

If the host firewall is configured correctly, the restriction may exist outside your OS. As a dedicated server user, check your provider's control panel.

Locate Security Groups, Hardware Firewalls, or Network ACLs in your client dashboard.
Verify that an inbound rule exists allowing the correct destination port and specific protocol (TCP or UDP).
If no provider firewall is active, the issue could involve upstream routing, missing public IP configurations, or an ISP block.

Step 6: Advanced Diagnostics with TCPDump

To definitively prove where a connection is failing, use tcpdump to capture network traffic arriving at your server.

Run this command on your server (monitoring all interfaces for a specific TCP port):

Bash

sudo tcpdump -ni any 'tcp port <port_number>'

While this runs, attempt to connect to the port from your local workstation.

How to read the capture:

Incoming SYN packets are visible: The TCP connection attempt is reaching your server. The issue lies within the server itself (check listening sockets, host firewall drops, and outbound routing for the response).
SYN followed by a RST packet: The connection is reaching the server but being actively rejected. Re-verify the IP/port binding and check for firewall REJECT rules.
SYN arrives, but no response is sent: The packet reached the server, but the system dropped it. Check the host firewall DROP rules or kernel routing behavior.
No packets are captured: The filter may be incorrect, the client may be querying the wrong IP/IPv6 address, or the traffic is being blocked upstream (provider network firewall, routing failure, or client-side ISP).

FAQ

Why is my port 80 or 443 blocked?

If you cannot access your web server, you must verify the web server's listening state, ensure the host firewall allows traffic, and check your provider's network filtering policies. For HTTPS (443), you must also independently verify your TLS/SSL configuration.

Is netstat deprecated in Linux?

While netstat (part of net-tools) may still be available on some systems, ss is generally preferred for modern Linux socket troubleshooting. It provides faster execution, deeper TCP state information, and is actively maintained.

Does a reboot fix a blocked port?

Generally, no. A reboot may resolve transient crashes or stuck processes, but it will not fix misconfigured bind addresses, missing firewall rules, or incorrect Docker port mappings. Always check system logs and network states before relying on a reboot.

Need Further Assistance?

If you have verified the listening states and firewall rules but still cannot connect, please open a support ticket. Include the output of your ss -tulnp and tcpdump tests to expedite troubleshooting. (Note: Please redact any sensitive data, such as passwords or private keys, from your logs before sharing).