Nginx配置upstream后转发异常，目标服务器返回404如何解决？

Let’s walk through the most common reasons your Nginx load balancing setup is throwing "404 - Resource not found" errors, along with practical fixes to get things working again:

1. Mismatched Request Paths Between Nginx and Upstream Servers #

This is the #1 culprit. By default, Nginx forwards the full request path to your upstream servers. If your backend app isn’t listening on that exact path, it’ll return a 404.

For example:

• User requests https://your-domain.com/api/users
• Nginx forwards this to http://backend-server/api/users
• But your backend app only serves content at http://backend-server/users (no /api prefix)

Fix: Adjust the proxy_pass directive to strip the unnecessary path prefix. Notice the trailing slash—it matters!

location /api/ {
    proxy_pass http://your_upstream/;  # Trailing slash removes the /api prefix
    proxy_set_header Host $host;
}

Or, if you can’t change the Nginx config, update your backend’s routing to match the path Nginx is sending.

2. Missing or Incorrect Host Header #

Most upstream servers (especially those using virtual hosts, like Apache or multi-tenant apps) rely on the Host HTTP header to know which site or service to serve. If Nginx doesn’t pass this header correctly, the backend might route your request to the wrong virtual host—resulting in a 404.

Fix: Add this line to your location block to pass the original request’s Host header to the upstream:

proxy_set_header Host $host;

If your backend expects a specific Host (e.g., backend.internal), you can hardcode it instead:

proxy_set_header Host backend.internal;

3. Forgetting to Specify Non-Standard Ports on Upstream Servers #

If your backend isn’t listening on the default 80 (HTTP) or 443 (HTTPS) ports, and you didn’t include the port in your upstream block, Nginx will default to port 80. Trying to reach a service running on, say, 8080 via port 80 will obviously result in a 404 (or connection refusal).

Fix: Include the correct port in your upstream definition:

upstream your_upstream {
    server 10.0.0.5:8080;  # Explicitly specify the backend's port
    server 10.0.0.6:8080;
}

4. Firewall/Security Group Blocking Nginx’s Requests #

Sometimes the 404 isn’t actually a "resource not found"—it’s the backend’s way of rejecting requests from unauthorized IPs. If your upstream server’s firewall or cloud security group doesn’t allow traffic from your Nginx server’s IP, it might return a custom 404 instead of a connection error.

Fix:

• Test directly from your Nginx server: Run curl http://backend-ip:port/your-requested-path
• If that returns a 404 too, check the backend’s firewall rules to whitelist your Nginx server’s IP address.

5. Stale Cached 404 Responses #

If you had a bad configuration earlier, Nginx might have cached the 404 response. Even after fixing the issue, it’ll keep serving the cached error until the cache expires.

Fix:

• If you’re using Nginx caching, clear the cache directory (usually /var/cache/nginx/)
• Or temporarily disable caching to test:

  proxy_cache_bypass $http_pragma;
  proxy_no_cache $http_pragma;
  

• Restart Nginx to apply changes: sudo systemctl restart nginx

6. Incorrect Document Root on the Upstream Server #

If your upstream is a static file server or uses something like PHP-FPM, double-check its document root configuration. If the backend’s root or document_root points to the wrong directory, the requested files simply won’t exist—leading to a 404.

Fix: Log into the upstream server and verify its web server config. For example, in an upstream Nginx server, check that the root directive points to the correct folder:

server {
    listen 8080;
    root /var/www/correct-app-directory;  # Make sure this path is right
    ...
}

Quick Debugging Tip #

Start by testing the upstream directly from your Nginx server with curl. If that returns a 404, the problem is with the backend—not Nginx. If it works, then the issue is definitely in your Nginx config.

内容的提问来源于stack exchange，提问作者aleks.n.fedorov