Nginx反向代理是移动端App API免跨域最常用方案，通过统一域名入口使请求“看似同源”，天然规避CORS；需正确配置proxy_pass尾部/、Host头、HTTPS终结及客户端证书校验，并避免后端重复添加CORS头。
直接在 Nginx 层面对移动端 App 的 API 请求做反向代理，是最常用且有效的免跨域方案。关键不是“绕过跨域”，而是让 App 发起的请求**看起来像同源请求**——即 App 域名（如 https://app.example.com）与后端 API（如 https://api.internal:8080）在浏览器视角下被统一收口到同一个域名和协议下，从而天然规避 CORS 限制。
将 App 域名作为统一入口，反向代理至内部 API
移动端 App 通常不走浏览器，本身没有同源策略限制；但若 App 内嵌 WebView 或使用某些混合框架（如 Cordova、React Native 的 WebView 组件），仍可能触发 CORS。更常见的是：App 直接调用 API，而你希望前端 H5 页面或调试环境也能复用同一套接口地址，此时需统一出口。
配置示例（Nginx）：
location /api/ {
proxy_pass https://www.php.cn/link/7548329c2fff56d8d1b3dabb8959b6d6;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
<pre class='brush:php;toolbar:false;'># 可选：为 WebView 场景显式放行 CORS（纯原生 App 不需要）
add_header 'Access-Control-Allow-Origin' '*';
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, PUT, DELETE';
add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization';
add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range';}
-
重点是
proxy_pass后带尾部/：确保路径重写正确，比如/api/users会转发为https://www.php.cn/link/7548329c2fff56d8d1b3dabb8959b6d6users，而非.../api/users。 - 若后端 API 依赖原始 Host 头做租户识别或路由，保留
proxy_set_header Host并设为真实后端域名（如api.internal）。 - 纯原生 App（iOS/Android HTTP 客户端）无需加 CORS 头；仅当混合页面或调试用浏览器访问
/api/时才需要。
按 User-Agent 区分流量，动态代理或限流
可识别 App 自定义 UA（如 MyApp/2.3.1 (iOS; iPhone14,2)），实现差异化处理：
map $http_user_agent $is_app {
~*MyApp/ 1;
default 0;
}
<p>server {
location /api/ {
proxy_pass <a href="https://www.php.cn/link/7548329c2fff56d8d1b3dabb8959b6d6">https://www.php.cn/link/7548329c2fff56d8d1b3dabb8959b6d6</a>;</p><h1>… 其他 proxy_* 配置</h1><pre class='brush:php;toolbar:false;'> # 仅对 App 流量关闭 CORS（避免暴露给网页）
if ($is_app) {
add_header 'Access-Control-Allow-Origin' '';
}
}}
- 用
map提前定义变量，比if更高效；if仅用于 header 控制等轻量操作。 - 也可基于
$is_app做限流（limit_req）、日志标记或灰度路由（如代理到api-v2.internal）。
HTTPS 终结 + 客户端证书校验（高安全场景）
对金融、支付类 App，可在 Nginx 终止 HTTPS，并验证客户端证书，确保只有合法 App 实例能访问 API：
ssl_client_certificate /etc/nginx/certs/app-ca.crt;
ssl_verify_client on;
ssl_verify_depth 2;
<p>location /api/ {</p><h1>… proxy 配置</h1><pre class='brush:php;toolbar:false;'>proxy_set_header X-Client-Verify $ssl_client_verify;
proxy_set_header X-Client-DN $ssl_client_s_dn;}
- App 打包时内置私钥和证书，每次请求携带；Nginx 验证签名及有效期。
- 后端可通过
X-Client-Verify和X-Client-DN获取认证结果，无需重复验签。 - 注意：需 App 端主动配置 TLS 双向认证（如 OkHttp 的
SSLSocketFactory，iOS 的NSURLSessionDelegate）。
避免常见陷阱
- 不要在后端再加 CORS 中间件：Nginx 已代理并添加了头，后端再加会导致重复 header 报错或覆盖。
-
Cookie 传递需显式开启：若 API 依赖 session cookie，加
proxy_cookie_path / "/; Secure; HttpOnly; SameSite=Lax";并确保proxy_pass协议与前端一致（HTTPS → HTTPS）。 -
健康检查与超时要匹配业务：移动端网络不稳定，建议
proxy_connect_timeout 5s;、proxy_read_timeout 30s;，并配合上游 keepalive。
