Port Access Failed? Check These Three Gates: Process, Firewall, Security Group

Three Gates of Port Accessibility

When a service works locally via curl but fails externally, the issue typically lies in one of three layers: the process must be listening on the correct address, the host firewall must allow the port, and the cloud provider's security group must permit inbound traffic. Troubleshooting is fastest from the outermost layer inward.

Gate 1: Is the Process Listening?

Check TCP listeners with ss -tlnp or lsof -i:PORT. Key output fields:

LISTEN – the socket is actively listening.

0.0.0.0:PORT – listening on all interfaces (accessible externally).

127.0.0.1:PORT – listening only on loopback; external access will never succeed. Change the bind address to 0.0.0.0 or keep it internal and expose via an Nginx reverse proxy.

users – shows the owning process.

If you see 127.0.0.1:xxx , do not check the firewall yet. The process only accepts local connections. Either rebind to 0.0.0.0 or (more securely) keep it on loopback and use Nginx to proxy external requests.

Gate 2 (Ubuntu/Debian): ufw

Ubuntu and Debian use ufw for straightforward rule management:

sudo ufw status              # view status
sudo ufw status verbose      # detailed rules
sudo ufw enable              # enable firewall
sudo ufw allow 80/tcp        # allow port 80
sudo ufw allow 8000:8010/tcp # allow port range
sudo ufw deny 3306           # deny port (default is deny)
sudo ufw delete allow 80/tcp # remove rule
sudo ufw allow from 10.0.0.5 to any port 22  # restrict SSH to specific IP

When working remotely, always allow 22/tcp before enable ; otherwise the firewall will cut your SSH session and you will lose access to the server.

Gate 2 (CentOS/RHEL): firewalld

CentOS and RHEL use firewalld, which requires a two-step permanent rule workflow:

sudo firewall-cmd --state                # check if running
sudo firewall-cmd --list-all             # view all rules
sudo firewall-cmd --permanent --add-port=80/tcp  # permanently allow port 80
sudo firewall-cmd --reload               # reload to apply permanent rules
sudo firewall-cmd --list-ports           # list allowed ports

The --permanent and --reload steps are both mandatory: without --permanent the rule disappears on reboot; without --reload the permanent rule does not take effect immediately.

Choose the tool based on your distribution: Ubuntu uses ufw, CentOS uses firewalld; both manipulate iptables/nftables underneath. Note that Docker manages its own port forwarding; even if the host firewall blocks a port, Docker's -p mapping can expose container ports (e.g., MySQL 3306, Redis 6379) to the public internet. Avoid mapping sensitive ports directly to public interfaces.

Gate 3: Cloud Security Group

Cloud providers (Alibaba Cloud, Tencent Cloud, AWS) enforce an additional security group outside the instance. It operates independently of the host firewall; both must allow traffic for a connection to succeed (logical AND). Configuration steps:

Open the console, navigate to the instance's security group, and edit rules.

Add an inbound rule: protocol TCP, port 80/443 (or your application port), source 0.0.0.0/0.

For SSH (port 22), restrict the source IP; do not open it to the entire internet.

A common mistake is configuring only one layer (host firewall or security group) and wondering why the port remains unreachable. Both must be open.

Complete Four-Step Diagnostic Checklist

Execute these steps in order; each yields a definitive conclusion:

# 1. On the server: is the process listening on 0.0.0.0?
ss -tlnp | grep 8000

# 2. On the server: does local access work?
curl -I http://127.0.0.1:8000

# 3. On the server: is the firewall allowing the port?
sudo ufw status | grep 8000   # or firewall-cmd --list-ports

# 4. From an external machine: is the port reachable?
curl -I http://SERVER_IP:8000

Symptom-to-Conclusion Mapping

Step 1 shows no output – process not running, or bound only to 127.0.0.1.

Step 2 fails – application-level issue; check application logs.

Step 2 succeeds but step 3 shows no rule – add the missing firewall rule.

Firewall allows but step 4 still fails – check the cloud security group in the provider console.

Common Port Exposure Principles

22 (SSH) – restrict to specific source IPs.

80 / 443 (HTTP/HTTPS) – open to public.

3306 (MySQL) – do not expose publicly; use internal network or reverse proxy.

6379 (Redis) – do not expose (high risk of unauthorized access).

8080 / 8000 (custom app ports) – open as needed, preferably behind Nginx reverse proxy.

Port reachability is not a single switch but a three-layer structure of listening, firewall, and security group . Remember to troubleshoot from the outermost layer inward to avoid wasted effort.

Further reading: service management with systemd ( systemd Service Management Explained ); daily command reference ( Linux Common Commands Cheat Sheet ). Next in the operations series: Linux File Permissions and User Management , covering chmod / chown numeric and symbolic modes.