Nginx中API跨域访问权限控制：结合Auth_basic配置教程-Nginx-PHP中文网

在nginx中需同时配置cors与auth_basic时，必须显式处理options预检请求并使用add_header ... always确保401响应也携带cors头，且access-control-allow-origin不能为*而须指定具体域名。

nginx中api跨域访问权限控制：结合auth_basic配置教程

在 Nginx 中，对 API 接口做跨域（CORS）支持的同时叠加基础认证（auth_basic），需注意两者协同工作的顺序和头信息冲突问题。关键点是：跨域响应头必须在认证通过后返回，且不能被认证流程拦截或覆盖；同时要避免浏览器因缺少预检响应（OPTIONS）而拒绝带认证的跨域请求。

启用并正确配置 CORS 响应头

仅靠 add_header 无法为 OPTIONS 预检请求返回 CORS 头，因为该指令默认不作用于 204/304/401 等响应。需显式处理 OPTIONS 请求，并确保所有涉及跨域的响应（包括 401）都携带必要头：

使用 location 块匹配 API 路径（如 /api/），并在其中统一设置 Access-Control-Allow-Origin、Access-Control-Allow-Methods、Access-Control-Allow-Headers 和 Access-Control-Allow-Credentials: true
对 OPTIONS 请求单独返回 204，并带上全部 CORS 头，不触发 auth_basic
若允许凭据（如 Cookie 或 Authorization），Access-Control-Allow-Origin 不能为 *，必须指定明确的前端域名（如 https://myapp.com）

将 auth_basic 与 CORS 安全结合

auth_basic 会返回 401 响应，此时浏览器期望看到合法的 CORS 头才能接受该响应。否则前端 fetch 会直接报 “CORS error”，甚至看不到 401 状态。解决方法：

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

在启用 auth_basic 的 location 块中，用 add_header 显式添加 CORS 头，并配合 always 参数，确保 401 响应也携带这些头
示例写法：add_header Access-Control-Allow-Origin "https://myapp.com" always;
注意：Nginx 1.7.5+ 才支持 always 参数，旧版本需用第三方模块（如 headers-more-nginx-module）或改用 Lua 实现

完整配置示例（含 OPTIONS 预检与认证）

以下是一个生产可用的最小化配置片段，假设 API 路径为 /api/，用户认证文件为 /etc/nginx/.htpasswd：

location /api/ {
    # 允许预检请求直接通过，不校验权限
    if ($request_method = 'OPTIONS') {
        add_header Access-Control-Allow-Origin "https://myapp.com";
        add_header Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS";
        add_header Access-Control-Allow-Headers "DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization";
        add_header Access-Control-Allow-Credentials "true";
        add_header Access-Control-Max-Age 86400;
        add_header Content-Length 0;
        add_header Content-Type text/plain;
        return 204;
    }
<pre class="brush:php;toolbar:false;"># 实际接口启用基础认证
auth_basic "API Restricted";
auth_basic_user_file /etc/nginx/.htpasswd;

# 确保所有响应（含 401）都返回 CORS 头
add_header Access-Control-Allow-Origin "https://myapp.com" always;
add_header Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS" always;
add_header Access-Control-Allow-Headers "DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization" always;
add_header Access-Control-Allow-Credentials "true" always;
add_header Access-Control-Max-Age 86400 always;

# 代理到后端（例如上游服务）
proxy_pass http://backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;

}

调试与验证要点

配置生效后，务必逐项验证，避免“看似正常实则失效”：

用 curl 模拟预检请求：curl -I -X OPTIONS -H "Origin: https://myapp.com" -H "Access-Control-Request-Method: POST" http://your-api-domain/api/test，检查是否返回 204 及完整 CORS 头
用 curl 发起带认证的跨域请求：curl -H "Origin: https://myapp.com" -u user:pass http://your-api-domain/api/test，确认响应含 Access-Control-Allow-Origin 且状态为 200 或对应业务码
在浏览器开发者工具 Network 标签中查看真实请求，特别关注 OPTIONS 请求的响应头，以及后续 GET/POST 是否收到 401 并携带 CORS 头
若前端仍报错，检查是否启用了 withCredentials: true 但后端 Access-Control-Allow-Origin 写成了 * —— 这是常见硬性错误