Why You Still Need Nginx Even When Using Tomcat

Problems with Using Only Tomcat

When a browser sends an HTTP request it first resolves the domain via DNS. In Alibaba Cloud DNS a domain can bind at most three public IPs, so deploying Tomcat instances on three public servers becomes a hard limit. The article lists several practical problems:

Cannot scale beyond three Tomcat nodes because DNS only supports three IPs.

Running ten services would require 30 public‑IP servers, leading to high cost.

Each service would need its own domain, increasing DNS management overhead.

Purchasing many public IPs from cloud providers is expensive.

Public servers need firewalls and security operations, which are hard to manage at scale.

Tomcat cannot serve static files in a front‑end‑separated architecture; a dedicated static server like Nginx or Apache is required.

These issues relate to cost, security, and scalability.

Tomcat Deployment During Release

During a service release Tomcat becomes unavailable. If DNS still points to the three servers, one‑third of the requests will fail, which the author humorously says would get him “shot by the boss”.

Why DNS Cannot Solve the Issue

DNS only resolves domain names to IP addresses; it does not know the health of the underlying Tomcat instances. Therefore it cannot automatically drop failed IPs. Even if an operator manually removes an IP, the DNS TTL (default 10 minutes) delays propagation, causing continued client failures. Reducing TTL would increase request latency because clients must query DNS more often.

Nginx Health Check and Retry

Nginx can perform health checks and automatic retry. If a Tomcat node returns “connection refused”, Nginx marks the request as failed and forwards it to another healthy node. After a configurable number of failures (e.g., two) the node is temporarily removed from the upstream pool for 60 seconds, after which Nginx retries it. Clients never see the failure because the request is transparently retried.

upstream test {
    server 127.0.0.1:8001 fail_timeout=60s max_fails=2; # Server A
    server 127.0.0.1:8002 fail_timeout=60s max_fails=2; # Server B
}

Nginx Virtual Host and Reverse Proxy

Nginx can map multiple sub‑domains to different directories and act as a reverse proxy to Tomcat clusters. Example configuration for three sub‑domains:

http {
    include mime.types;
    default_type application/octet-stream;
    sendfile on;
    keepalive_timeout 65;
    server {
        listen 80;
        server_name www.abc.com;
        location / {
            root html/www;
            index index.html index.htm;
        }
    }
    server {
        listen 80;
        server_name bbs.abc.com;
        location / {
            root html/bbs;
            index index.html index.htm;
        }
    }
    server {
        listen 80;
        server_name blog.abc.com;
        location / {
            root html/blog;
            index index.html index.htm;
        }
    }
}

Internal Network Load Balancing Example

When Tomcat clusters run on an internal network, Nginx can define upstream groups with weight and backup servers, then proxy specific URL paths to each group:

upstream serverGroup1 {
    server 192.168.225.100:8080;               # default weight 1
    server 192.168.225.101:8082 weight=2;      # higher weight = more load
    server 192.168.225.102:8083;
    server 192.168.225.103:8084 backup;        # hot‑standby
}
upstream serverGroup2 {
    server 192.168.225.110:8080;
    server 192.168.225.111:8080 weight=2;
    server 192.168.225.112:8080;
    server 192.168.225.113:8080 backup;
}
server {
    listen 80;
    server_name picture.itdragon.com;
    location /group1 {
        root html;
        proxy_pass http://serverGroup1;
        index index.html index.htm;
        deny 127.0.0.1;
        allow 192.168.225.133;
    }
    location /group2 {
        root html;
        proxy_pass http://serverGroup2;
        index index.html index.htm;
        deny 127.0.0.1;
        allow 192.168.225.133;
    }
    error_page 500 502 503 504 /50x.html;
    location = /50x.html { root html; }
}

Conclusion

After experiencing DNS limits, release‑time failures, and lack of health checks, the author concludes that both Tomcat and Nginx are required for a robust, scalable web service. Only in a scenario with unlimited public IPs, domains, and resources could one consider dropping Nginx.