Why Using Nginx with Tomcat Is Essential: HTTP Flow, DNS Limits, Health Checks, and Configuration Examples

Using Only Tomcat Without Nginx: HTTP Request Flow

When a browser sends an HTTP request, it first resolves the domain name via DNS to obtain an IP address, then contacts the server at that IP; on Alibaba Cloud, a domain can bind at most three public IPs, so Tomcat instances must be deployed on three public‑IP servers.

Problems When Using Only Tomcat

DNS can bind at most three IPs, so expanding to four Tomcat instances is unsupported.

Ten services would require ten separate Tomcat clusters, i.e., 30 public‑IP servers, leading to high cost.

Each service needs its own domain, resulting in ten domains mapped to ten Tomcat clusters.

Purchasing ten domains is expensive (although sub‑domains could be used).

Public servers acting as entry points need firewalls and security management, which is hard to maintain for dozens of machines.

Public IP addresses must be bought from carriers or cloud providers, and thirty IPs are costly.

In a front‑end/back‑end separation scenario, Tomcat cannot serve static files; Nginx or Apache is required.

These issues relate to cost, security, and scalability.

Deploying Tomcat Services

During a service release, Tomcat becomes unavailable; any HTTP request hitting the releasing server fails. With only three DNS‑bound servers, the failure rate during deployment can be one‑third, which could get you fired.

Can DNS Automatically Remove Faulty IPs?

No. DNS only resolves domain names to IP addresses and has no knowledge of server or Tomcat status, so it cannot automatically drop failed IPs.

Can I Manually Remove Faulty IPs?

Yes, but requests will still fail until the DNS cache (TTL) expires. On Alibaba Cloud the default TTL is ten minutes, so even after manually removing an IP, clients may continue using the old address for up to ten minutes.

Reducing the TTL is possible, but it forces clients to query DNS more often, increasing overall latency and degrading user experience.

What If a Node Suddenly Crashes?

Manual removal is too slow for sudden crashes; you would have to inform the boss and wait for DNS propagation. An automated health‑check and retry mechanism would solve this, which is exactly where Nginx excels.

Nginx Can Perform Health Checks and Retry

Tomcat lacks built‑in health checking and failover.

Example of two Tomcat nodes with Nginx upstream configuration:

<code style="padding: 16px; color: #abb2bf; display: -webkit-box; font-family: Operator Mono, Consolas, Monaco, Menlo, monospace; font-size: 12px">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
}
</code>

If node A refuses connections, Nginx marks the request as failed and automatically forwards it to node B. After two consecutive failures, Nginx removes A from the active list for 60 seconds, then retries later, providing seamless failover without client awareness.

This transparent proxying shields clients from individual node outages or deployments.

10 Services, 10 Tomcat Clusters, 30 Public IPs?

Using Alibaba Cloud's sub‑domain mapping, a single public domain can be split into ten sub‑domains, reducing the need for ten separate domains.

Thus, only one public domain, ten sub‑domains, and thirty servers (or IPs) are required.

When the boss complains about the cost of dozens of public IPs, the solution is to let Nginx handle internal routing.

Mapping a domain directly to Tomcat IPs requires public IPs, which is costly; Nginx can map a single domain to many internal IPs.

Nginx Virtual Hosts and Reverse Proxy

Example of mapping multiple sub‑domains to different directories:

bbs.abc.com → html/bbs

blog.abc.com → html/blog

<code style="padding: 16px; color: #abb2bf; display: -webkit-box; font-family: Operator Mono, Consolas, Monaco, Menlo, monospace; font-size: 12px">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;
        }   
    }   
}
</code>

Mapping different sub‑domains or URL paths to distinct Tomcat clusters:

Define serverGroup1 and serverGroup2 as two Tomcat clusters.

Proxy /group1 and /group2 to the respective clusters.

<code style="padding: 16px; color: #abb2bf; display: -webkit-box; font-family: Operator Mono, Consolas, Monaco, Menlo, monospace; font-size: 12px">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 {
           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;
        }
    }
</code>

After learning these lessons, I will no longer make the mistake of using Tomcat alone; I need both Tomcat and Nginx.

If resources were unlimited—unlimited public IPs, domains, and servers—one could theoretically run without Nginx, but in realistic scenarios Nginx is indispensable.