原生 App 不受同源策略限制，通常无需配置 CORS；仅当内嵌 WebView、调试浏览器访问或混合框架场景才需添加 CORS 头，且须按需设置 Allow-Headers、Expose-Headers 及 OPTIONS 预检响应。
移动端 App（如 iOS/Android 原生客户端）本身不执行浏览器的同源策略，因此绝大多数情况下根本不需要配置 CORS。所谓“非标准跨域请求来源”，实际是指 App 通过自定义 User-Agent、携带特定业务头（如 X-App-Version、X-Device-ID）发起的 HTTP 请求——这类请求不会触发浏览器预检（OPTIONS），但后端或代理层可能需识别并响应这些头字段。
确认是否真需要 CORS 头
原生 App 的 HTTP 客户端（如 OkHttp、URLSession）默认不校验 Access-Control-Allow-Origin 等响应头，也不发送预检请求。只有以下场景才需加 CORS：
- App 内嵌 WebView 加载 H5 页面，并在页面 JS 中调用
/api/接口 - 开发调试阶段用 Chrome 浏览器直接访问 Nginx 代理的
/api/地址 - 混合框架（如 React Native、Flutter Webview）中运行前端逻辑
纯原生网络请求，Nginx 只需正常代理，无需任何 add_header Access-Control-* 指令。
支持自定义请求头（如 X-App-Version）
若 App 在请求中带了非标准头（例如 X-App-Version: 3.2.0），而前端 JS 需读取后端返回的对应响应头（如 X-Request-ID），则必须显式声明：
- 在
location /api/ { }块中添加：add_header Access-Control-Allow-Headers "X-App-Version,X-User-Role,X-Request-ID"; - 确保该字符串无空格、逗号后不跟空格，否则部分浏览器会拒绝请求
- 若 JS 需读取响应头，同步设置：
add_header Access-Control-Expose-Headers "X-Request-ID,X-RateLimit-Remaining";
按 User-Agent 区分 App 流量并差异化处理
可通过 $http_user_agent 变量识别 App 请求，实现路由、限流或日志标记：
- 示例匹配规则：
if ($http_user_agent ~* "MyApp/(\d+\.\d+\.\d+) \(iOS; .*\)") { set $app_version $1; } - 配合
proxy_set_header X-App-Version $app_version;，将版本透传给后端 - 也可用
map指令做更高效映射，避免重复 if 判断
预检请求（OPTIONS）必须显式拦截
即使 App 不发 OPTIONS，WebView 或调试浏览器会发。Nginx 默认不处理 OPTIONS，需主动拦截返回 204：
- 在
location /api/ { }内添加：if ($request_method = 'OPTIONS') { add_header Access-Control-Allow-Origin "*"; add_header Access-Control-Allow-Methods "GET,POST,PUT,DELETE,OPTIONS"; add_header Access-Control-Allow-Headers "X-App-Version,Authorization,Content-Type"; add_header Access-Control-Max-Age 1728000; add_header Content-Length 0; return 204; } - 注意：
Access-Control-Allow-Origin设为*时，Access-Control-Allow-Credentials必须省略或设为false；若需带 Cookie，则 Origin 必须写具体域名
