Fix connection refused
Topic: Networking basics
Summary
Connection refused means the destination host received the connection attempt but no process is listening on that port (or the kernel rejected it). Find what should be listening, start the service or fix the port, and ensure the firewall is not dropping before the listener. Use this when you get 'Connection refused' for SSH, HTTP, or any TCP service.
Intent: Troubleshooting
Quick answer
- On the destination host: run ss -tlnp or netstat -tlnp and check that the expected port has a listener; if not, start the service (e.g. systemctl start sshd, systemctl start nginx).
- Confirm the service listens on the right address: 0.0.0.0 (all interfaces) vs 127.0.0.1 (local only). If it listens on 127.0.0.1 only, remote clients get connection refused; change the service config to listen on 0.0.0.0 or the server's IP.
- If the firewall drops before the packet reaches the listener, some stacks return 'connection refused' or timeout; allow the port in the firewall and retry; from client use nc -zv HOST PORT to test.
Prerequisites
Steps
-
Confirm nothing is listening
On the server: ss -tlnp | grep :PORT (e.g. :22, :80). If no output, no process is bound to that port; start the correct service (systemctl start UNIT) or fix the service config to use that port.
-
Check listen address
If the service listens on 127.0.0.1:PORT only, connections from other hosts will be refused. Change the config to listen on 0.0.0.0:PORT or the server's IP; restart the service.
-
Rule out firewall
From the client, nc -zv SERVER PORT; if timeout instead of refused, a firewall may be dropping. On the server, allow the port (ufw allow PORT/tcp or nft rule); retry. Some environments return refused when the firewall drops; allow the port and ensure the service is listening.
-
Verify
After starting the service and fixing listen address and firewall, connect again from the client; ss -tlnp on the server should show the listener; connection should succeed.
Summary
“Connection refused” means no process is listening on the destination port (or the connection was rejected). Fix it by starting the right service, making it listen on 0.0.0.0 or the server IP (not 127.0.0.1 only), and allowing the port in the firewall. Use this when SSH, HTTP, or any TCP connection is refused.
Prerequisites
Steps
Step 1: Confirm nothing is listening
On the server:
ss -tlnp | grep :22
If nothing is listening on that port, start the service (e.g. systemctl start sshd) or fix the service config so it binds to that port.
Step 2: Check listen address
If the service is listening on 127.0.0.1 only, it will not accept connections from other hosts. Change the service configuration to listen on 0.0.0.0 or the server’s IP, then restart the service.
Step 3: Rule out firewall
From the client: nc -zv SERVER PORT. If you get a timeout, a firewall may be dropping. On the server, allow the port (e.g. ufw allow 22/tcp) and retry. Ensure the service is actually listening after the firewall is open.
Step 4: Verify
After starting the service, fixing the listen address, and allowing the port, connect again. On the server, ss -tlnp should show the listener on the expected address and port.
Verification
- The port has a listener on the correct address; the client can connect (e.g. SSH or nc).
Troubleshooting
Service starts then exits — Check logs (journalctl -u UNIT); config error or missing dependency can cause immediate exit; fix config and restart.
Still refused after opening firewall — Confirm the service is listening (ss -tlnp); confirm the client is connecting to the right IP and port; check for multiple firewalls (host and network).