Alright, let's break down that mysterious 999 HTTP status code you're seeing from Tomcat, and walk through exactly what's going on with your access log entry.

What's a 999 Status Code in Tomcat? #

First off, this isn't a standard HTTP status code you'll find in official RFC specs. Tomcat uses 999 as an internal marker to indicate that the client (or an intermediary like a proxy) closed the connection before the server could send a full response. It's not a server-side error in the traditional sense—it's a sign that the connection was terminated early from the other end.

Common Triggers for 999 Status Codes #

Here are the most frequent reasons you'll see this pop up:

• The client (browser, API client, etc.) hit its own timeout threshold and closed the connection before Tomcat finished processing the request.
• A user refreshed or closed their browser tab mid-request, killing the connection.
• A reverse proxy or load balancer in front of Tomcat has a short timeout setting, so it cuts off the connection before Tomcat can respond.
• Flaky network conditions caused the connection to drop unexpectedly.

Digging Into Your Specific Log Entry #

Let's start by looking at your log line, formatted for clarity:

[12/Mar/2018:10:27:30 +0100] 172.19.160.65 - 172.19.160.71 POST 8081 999

Breaking down the key parts:

• 172.19.160.65: This is the client IP (could be a direct client or a proxy server sitting between the user and Tomcat)
• 172.19.160.71: Your Tomcat server's IP
• POST: The request was a POST, meaning it was sending data to your server (like a form submission or API payload)
• 8081: The Tomcat port handling the request
• 999: The status code we're investigating

Likely Causes for This Specific Entry #

Given it's a POST request, here are the most probable scenarios:

1. Slow request processing: The POST endpoint might be running a time-consuming operation—think heavy database queries, calls to external APIs, or large data processing. If it takes longer than the client/proxy's timeout setting, the connection gets closed early.
2. Client-side action: The user who sent the POST might have closed their browser, refreshed the page, or navigated away before the request finished.
3. Intermediary timeout: If there's a proxy or load balancer between the client and Tomcat, check its timeout configuration. It might be set too low, causing it to terminate connections before Tomcat can send a response.

To narrow it down, you could:

• Check Tomcat's server logs (like catalina.out) for any signs of slow processing or errors in that POST endpoint around the timestamp 12/Mar/2018:10:27:30 +0100
• Test the POST endpoint directly to see how long it takes to respond
• Verify timeout settings on any proxies/load balancers in your setup

内容的提问来源于stack exchange，提问作者Amara Ghoufa