Why Tomcat Alone Isn’t Enough: Leveraging Nginx for Reliable Web Services

When a browser sends an HTTP request, it first resolves the domain name via DNS to an IP address. In many cloud providers, a domain can bind at most three public IPs, forcing you to deploy Tomcat instances on separate public servers and quickly hitting scalability, cost, and security limits.

Scaling and Cost Problems

DNS limits to three IPs prevent expanding beyond three Tomcat nodes.

Ten services each requiring a Tomcat cluster would need 30 public IPs, dramatically increasing expense.

Each service would also need its own domain, further inflating DNS costs.

Public servers must be firewalled and maintained, adding operational overhead.

Public IPs must be purchased from carriers, which is costly.

Tomcat cannot serve static assets in a front‑end‑back‑end separation, unlike Nginx or Apache.

During a Tomcat deployment the server is unavailable, so any request hitting the updating node fails. With only three DNS‑bound IPs, the failure rate can reach one‑third, which is unacceptable in production.

DNS Limitations

DNS merely maps domain names to IP addresses; it does not know server health or Tomcat status, so it cannot automatically drop faulty IPs. Manual removal is possible but constrained by TTL settings—defaulting to ten minutes—meaning clients continue to receive stale IPs for that period.

Health Checks and Automatic Retry

Nginx provides built‑in health checking and fail‑over capabilities that Tomcat lacks. An example upstream configuration demonstrates how Nginx can mark a node as failed after two connection refusals and temporarily remove it from the load‑balancing pool for 60 seconds, automatically routing subsequent requests to a healthy node without client awareness.

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
}

This mechanism ensures continuous service availability even when a Tomcat instance crashes or is being redeployed.

Domain and IP Optimization with Subdomains

Using subdomains can reduce the number of required public IPs. A single public domain can be split into multiple subdomains, each pointing to a different Tomcat cluster, allowing ten services to operate with only one public domain, ten subdomains, and thirty public IPs.

Nginx Virtual Hosts and Reverse Proxy for Multiple Services

Below is a sample Nginx configuration that maps distinct subdomains to separate document roots and also proxies URL paths to different Tomcat clusters.

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;
        }
    }
}

To forward requests to Tomcat clusters, define upstream groups and use proxy_pass within location blocks:

upstream serverGroup1 {
    server 192.168.225.100:8080;
    server 192.168.225.101:8082 weight=2;
    server 192.168.225.102:8083;
    server 192.168.225.103:8084 backup;
}
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 {
        proxy_pass http://serverGroup1;
    }
    location /group2 {
        proxy_pass http://serverGroup2;
    }
    error_page 500 502 503 504 /50x.html;
    location = /50x.html {
        root html;
    }
}

In summary, while Tomcat serves as the Java web container, Nginx adds essential features such as health checks, load balancing, static file serving, and flexible domain routing, making it indispensable for production‑grade deployments unless resources are unlimited.