Nginx反向代理：访问/后无法匹配/app1/ location规则问题咨询

Let's walk through your issues step by step—this is a common set of pitfalls when setting up Nginx with multiple upstreams and location rules.

1. Why isn't the root path / matching the /app1/ location rule? #

First, let's clarify how Nginx's location matching works: it's based entirely on the request URI sent by the client. If a user visits http://yourdomain/, their request URI is /—this will only match location rules that target / (or catch-all regex rules that include /). The /app1/ location rule only kicks in when the request URI starts with /app1/ (e.g., http://yourdomain/app1/).

Your suspicion about ip_hash is a bit off track here—ip_hash is an upstream directive that ensures the same client IP is routed to the same backend server within a single upstream pool. It doesn't affect which location rule Nginx selects for a given request.

That said, if you're expecting visits to / to be routed to the /app1/ backend, you're missing either a rewrite rule or a redirect. For example:

• To rewrite the URI internally (so the client still sees / in their browser but Nginx sends the request to /app1/):

  location / {
      rewrite ^/$ /app1/ last;
  }
  
  location /app1/ {
      proxy_pass http://app1_upstream;
      # Add your other proxy settings here (like proxy_set_header)
  }
  

• To redirect the client's browser to /app1/ (so the URI changes in their address bar):

  location / {
      return 302 /app1/;
  }
  

If you already have this setup and it's still not working, double-check that your /app1/ rule isn't being overridden by a higher-priority rule (like a regex location that matches / first). Remember: regex locations take precedence over prefix locations unless you use the ^~ modifier on a prefix location.

2. Is this behavior normal? #

If you're seeing that / doesn't match /app1/, yes, that's completely normal—it's how Nginx's location matching is designed to work. The only time this would be abnormal is if you explicitly configured / to route to /app1/ and it's not doing so (which would point to a configuration error, like misplaced directives or incorrect rewrite syntax).

3. Key considerations for your two reverse proxy servers (Internet vs. LAN) #

Running separate proxies for external and internal users is a smart practice—here are a few tips to optimize this setup:

• Security hardening: For the internet-facing proxy, enforce HTTPS with valid certificates, add rate limiting (limit_req_zone), restrict access to sensitive paths (e.g., /admin/) with allow/deny rules, and enable security headers (like X-Frame-Options or Content-Security-Policy). The LAN proxy can be more permissive since it's behind your firewall.
• Upstream separation: You might want distinct upstream pools for each proxy. For example, the internet proxy could route to public-facing backend servers, while the LAN proxy can access internal-only services that never need to be exposed externally.
• Session consistency: If you're using ip_hash (or another session persistence method), make sure each proxy's upstream configuration aligns with its backend pool. There's no need to sync session state between the two proxies unless users regularly switch between internet and LAN access (in which case a shared session store like Redis would help).
• Logging differentiation: Configure separate log files for each proxy so you can easily distinguish internet traffic from LAN traffic. This simplifies troubleshooting and security audits.

内容的提问来源于stack exchange，提问作者Flávio Cardoso