Resolving CORS Issues with Nginx Proxy Configuration

This article explains how to troubleshoot and solve Cross-Origin Resource Sharing (CORS) problems when a front‑end site (http://localhost:8080) accesses a back‑end service (http://localhost:59200) through Nginx.

Key CORS response headers

Access-Control-Allow-Origin : specifies allowed origin.

Access-Control-Allow-Headers : lists permitted custom request headers.

Access-Control-Allow-Methods : lists allowed HTTP methods.

Access-Control-Allow-Credentials : indicates whether cookies can be sent.

The typical error occurs because the preflight OPTIONS request does not receive the required headers, leading to messages such as:

Access to XMLHttpRequest at 'http://localhost:22222/api/Login/TestGet' from origin 'http://localhost:8080' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Step‑by‑step Nginx configuration

1. Basic proxy setup (port 22222):

server {
    listen 22222;
    server_name localhost;
    location / {
        proxy_pass http://localhost:59200;
    }
}

2. Add the Access-Control-Allow-Origin header for normal requests:

add_header Access-Control-Allow-Origin 'http://localhost:8080' always;

3. Handle preflight OPTIONS requests by returning 204 and supplying all required headers:

if ($request_method = 'OPTIONS') {
    add_header Access-Control-Allow-Origin 'http://localhost:8080';
    add_header Access-Control-Allow-Headers 'authorization,content-type';
    add_header Access-Control-Allow-Methods 'GET,POST,PUT,DELETE,OPTIONS';
    add_header Access-Control-Allow-Credentials 'true';
    return 204;
}

4. Ensure that the always flag is used only for non‑OPTIONS responses; otherwise the header may be omitted for preflight checks.

Common pitfalls

Missing Access-Control-Allow-Origin in the OPTIONS block.

Not adding Access-Control-Allow-Headers for custom headers such as authorization .

Forgetting to allow the HTTP method used (e.g., PUT ) in Access-Control-Allow-Methods .

Returning multiple Access-Control-Allow-Origin values (e.g., * and a specific domain) which violates the CORS spec.

By separating the handling of normal requests and preflight requests, the CORS errors are eliminated. The final, robust configuration can be simplified to:

server {
    listen 22222;
    server_name localhost;
    location / {
        if ($request_method = 'OPTIONS') {
            add_header Access-Control-Allow-Origin 'http://localhost:8080';
            add_header Access-Control-Allow-Headers '*';
            add_header Access-Control-Allow-Methods '*';
            add_header Access-Control-Allow-Credentials 'true';
            return 204;
        }
        add_header Access-Control-Allow-Origin 'http://localhost:8080' always;
        add_header Access-Control-Allow-Credentials 'true';
        proxy_pass http://localhost:59200;
    }
}

Using this configuration, the front‑end can successfully call the back‑end APIs without CORS interruptions.