基于Nginx与AKS Istio架构的CORS Allow Origin Not Matching Origin问题排查求助

Let’s dig into this tricky CORS issue—since you’ve verified the origin matches across all layers, the problem is almost certainly hiding in a subtle configuration conflict or overlooked detail. Here’s how to diagnose and fix it:

1. Check for Duplicate Access-Control-Allow-Origin Headers #

The most common culprit here is multiple Access-Control-Allow-Origin headers in the response. Even if each individual header matches your origin, browsers reject responses with more than one of these headers.

How to Verify: #

Run this curl command to inspect the response headers:

curl -H "Origin: https://mysite.domain" -I https://your-target-api-endpoint

Look for repeated Access-Control-Allow-Origin entries in the output.

Fix: #

Pick one layer to handle CORS configuration and remove the rules from the other two. For example:

• Keep only the Istio virtual service CORS policy, and delete the add_header rules from both Nginx servers.
• Or, keep the outermost Nginx TLS server’s CORS rules, and disable CORS in the second Nginx proxy and Istio.

2. Resolve Istio’s Credentials + Wildcard Origin Conflict #

Your Istio configuration has a critical violation of CORS standards: you’ve set allowCredentials: true alongside allowOrigins: exact: '*'.

Per CORS rules, when Access-Control-Allow-Credentials is true, Access-Control-Allow-Origin cannot be a wildcard (*)—it must be an exact, specific origin. Even if your browser seemed to tolerate this when bypassing Nginx, the layered proxies are likely triggering the strict validation.

Fix: #

Update your Istio virtual service to use your exact origin:

corsPolicy:
    allowCredentials: true
    allowHeaders:
    - authorization
    - content-type
    allowMethods:
    - GET
    - POST
    - OPTIONS
    - PUT
    - DELETE
    allowOrigins:
    - exact: 'https://mysite.domain'

3. Ensure Nginx Properly Handles OPTIONS Preflight Requests #

Preflight OPTIONS requests are sent by browsers before actual API calls, and they need special handling. If your Nginx servers aren’t responding correctly to OPTIONS, it can trigger misleading origin mismatch errors.

Fix: #

Add this block to each Nginx server’s location block to directly respond to OPTIONS requests (no need to forward them upstream):

if ($request_method = OPTIONS) {
    add_header 'Access-Control-Allow-Origin' 'https://mysite.domain' always;
    add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, PUT, DELETE' always;
    add_header 'Access-Control-Allow-Headers' 'Authorization, Content-Type' always;
    add_header 'Access-Control-Max-Age' 1728000; # Cache preflight response for 20 days
    add_header 'Content-Type' 'text/plain; charset=utf-8';
    add_header 'Content-Length' 0;
    return 204;
}

4. Use Nginx’s always Parameter for CORS Headers #

By default, Nginx’s add_header only applies to responses with 2xx/3xx status codes. If your API returns a 4xx/5xx error, the CORS headers won’t be added, leading to an origin mismatch error.

Fix: #

Add the always keyword to all your Nginx add_header directives to ensure they’re included in every response:

add_header 'Access-Control-Allow-Origin' 'https://mysite.domain' always;
add_header "Access-Control-Allow-Methods" "GET, POST, OPTIONS, PUT, DELETE" always;
add_header "Access-Control-Allow-Headers" "Authorization, Content-Type" always;

Final Testing #

After applying these fixes, clear your browser cache, restart all Nginx servers, and refresh Istio’s virtual service configuration. Test the API call again—this should resolve the "Allow Origin Not Matching Origin" error.

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