From 'no route to host' to virtual host

From 'no route to host' to virtual host: debugging standalone Nginx and cloud networking#

I recently deployed a standalone NGINX instance listening directly on port 80 in a cloud environment. While deploying a basic web server appears straightforward, terminal troubleshooting frequently surfaces low-level realities: kernel port capabilities, packet filter ordering, and cloud boundary ingress rules.

Here is the practical workflow: from the NGINX master-worker lifecycle to diagnosing the No route to host network error and deploying modular Virtual Hosts (server blocks).

1. Starting baseline: standalone Nginx on privileged ports#

To bind to default HTTP port 80, the basic server {} configuration block is:

server {
    listen 80 default_server;
    listen [::]:80 default_server; # IPv6 support
    server_name _;

    location / {
        root /usr/share/nginx/html;
        index index.html;
    }
}

For high-concurrency multi-core systems, optimize the listen directive with the reuseport kernel flag:

listen 80 default_server reuseport;

Kernel mechanics: master-worker and capabilities#

Port 80 resides in Linux's privileged range (0 to 1023):

The NGINX Master process starts as root to execute socket() and bind() syscalls requiring CAP_NET_BIND_SERVICE.
Following listen(), the Master forks unprivileged Worker processes, dropping privileges via setuid() and setgid() to user nginx or www-data to protect the host.

To run the binary directly without root, grant capabilities to the executable:

setcap 'cap_net_bind_service=+ep' /usr/sbin/nginx

2. The symptom: "no route to host" on the public IP#

Testing external connectivity against the instance's public IP (203.0.113.10):

telnet 203.0.113.10 80
# Trying 203.0.113.10...
# telnet: Unable to connect to remote host: No route to host

Checking active listening sockets with ss -tulpn:

tcp   LISTEN 0      511            0.0.0.0:80        0.0.0.0:*    users:(("nginx",pid=4356,fd=5))
tcp   LISTEN 0      511               [::]:80           [::]:*    users:(("nginx",pid=4356,fd=6))

Testing locally over the loopback interface:

telnet 127.0.0.1 80
# Connected to 127.0.0.1.

Root cause analysis#

If the socket answers on 127.0.0.1:80, NGINX is healthy. The No route to host error (ICMP Type 3, Code 1) pointed to active packet rejection.

Inspecting route tables and iptables counters:

# Check iptables packet counters for port 80
iptables -L INPUT -n -v | grep :80
# 0     0 ACCEPT     6    --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80

Three factors caused the block:

Zero packet counter: The port 80 rule had 0 pkts, proving packets were dropped before reaching this chain or outside the OS.
Absence of Hairpin NAT: Outbound packets targeting the instance's own public IP routed to the default gateway (10.0.0.1), which did not loop traffic back.
Cloud provider ingress firewall: On cloud platforms like Oracle Cloud, AWS, or GCP, Security Lists and Network Security Groups block ingress on port 80 by default.

3. Firewall remediation#

Local iptables rule precedence:

Insert the allow rule at the top of the chain before any broad REJECT statements:

   iptables -I INPUT 1 -p tcp --dport 80 -j ACCEPT
   netfilter-persistent save

Cloud Security List ingress rule:

In the cloud console (VCN > Security Lists), add an ingress rule:

Source CIDR: 0.0.0.0/0
Protocol: TCP
Destination Port: 80

4. Implementing modular virtual hosts#

With network paths clear, deploy modular vHosts.

Inclusion in /etc/nginx/nginx.conf#

Inside the http {} block:

http {
    include /etc/nginx/sites-enabled/*;
}

Vhost configuration (/etc/nginx/sites-available/mysite.com.conf)#

server {
    listen 80;
    listen [::]:80;

    server_name mysite.com www.mysite.com;

    access_log /var/log/nginx/mysite.access.log combined buffer=16k;
    error_log /var/log/nginx/mysite.error.log warn;

    root /var/www/mysite.com/public_html;
    index index.html index.php;

    # Block access to hidden files (.git, .env, .htaccess)
    location ~ /\.(?!well-known).* {
        deny all;
        access_log off;
        log_not_found off;
    }

    location / {
        try_files $uri $uri/ /index.html;
        sendfile on;
        tcp_nodelay on;
        keepalive_timeout 65;
    }
}

Performance tip: sendfile on streams data directly from disk file descriptors to TCP sockets in Kernel Space, avoiding context switches to User Space memory.

Activation and graceful reload#

# 1. Create symlink
ln -s /etc/nginx/sites-available/mysite.com.conf /etc/nginx/sites-enabled/

# 2. Test syntax
nginx -t

# 3. Graceful reload (SIGHUP)
nginx -s reload

Simulating host headers locally#

To verify vHost matching before DNS propagation:

curl -H "Host: mysite.com" http://127.0.0.1

NGINX evaluates the Host header, routes to the matching server_name, and serves the virtual host content.

Best practices for Nginx networking and vhosts#

Step-by-step validation: Always test 127.0.0.1 first. If loopback responds, the application is healthy and the issue lies in network firewalls or routing rules.
Watch iptables rule ordering: Appending rules with -A places them at the bottom, often behind global REJECT lines. Use -I to enforce top priority.
Use sendfile and buffered logging: Enabling sendfile on and buffering access logs reduces CPU and disk I/O load on high-throughput servers.

Was this article helpful?

Leave a quick reaction to help prioritize future technical guides:

This post is licensed under CC BY-NC.