How to Quickly Fix CORS Issues with Simple Nginx Configuration

When a front‑end running at http://localhost:8080 tries to call a back‑end service at http://localhost:59200, browsers block the request due to the Same‑Origin Policy. The article first advises confirming that the back‑end itself does not set any CORS headers and that the API works with Postman.

The four key CORS response headers are introduced: Access-Control-Allow-Origin – specifies allowed request origins. Access-Control-Allow-Headers – lists permitted custom request headers (checked only on preflight). Access-Control-Allow-Methods – enumerates allowed HTTP methods (checked only on preflight). Access-Control-Allow-Credentials – indicates whether cookies may be sent; it must be set to true when needed, but the article warns against using it indiscriminately.

The concept of a preflight (OPTIONS) request is explained: browsers first send an OPTIONS request to verify that the server permits the requested method and headers. If the preflight fails, the actual request is never sent.

Initial Nginx proxy configuration (listening on port 22222 and proxying to the back‑end) is shown and tested. The first error (Situation 1) reports a missing Access-Control-Allow-Origin header. Adding the header with the front‑end origin and the always flag resolves this specific error.

In Situation 2 the preflight OPTIONS request returns no 2xx status. The fix is to add an if ($request_method = 'OPTIONS') block that returns 204, ensuring the browser receives a successful preflight response.

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

Situation 3 reveals a missing Access-Control-Allow-Headers entry for authorization. The header is added inside the same OPTIONS block, after which the error changes back to Situation 1, confirming that the missing origin header was still not being sent for non‑OPTIONS requests.

The article cites the Nginx documentation that add_header directives are inherited only when no add_header is defined at the current level, explaining why headers added inside the if block do not affect other requests.

Situation 4 deals with a PUT request that is not allowed by the default Access-Control-Allow-Methods. Adding PUT (or *) to the header inside the OPTIONS block resolves the error.

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

Situation 5 shows a case where the back‑end already sets CORS headers, causing Nginx to emit duplicate Access-Control-Allow-Origin values (e.g., * and the specific origin). The recommendation is to let either the back‑end or Nginx handle CORS, but not both.

Finally, two complete Nginx configurations are provided—one using * for headers and methods, and another with explicit values—demonstrating how to combine the always flag for non‑OPTIONS requests and a dedicated OPTIONS block that returns 204. The article concludes that understanding the preflight mechanism and correctly placing add_header directives is essential for reliably solving CORS problems with Nginx.