nginx适配不同前端架构的关键是按实际通信方式动态透传或补全关键请求头，而非更换模板；需精准处理host、origin、自定义header及websocket升级头，确保后端收到的请求与直连一致。
适配不同前端架构的关键，不是换模板，而是按前端实际通信方式动态传递关键请求头。Nginx 本身不区分 Vue、React 或 Svelte，它只认 HTTP 头——前端怎么发，后端怎么验，Nginx 就得怎么透传或补全。
单页应用（SPA）路由与 Host 处理
前端用 History 模式时，浏览器地址栏是 /user/profile，但真实请求仍走 /api/user/info 这类接口。后端依赖 Host 判断租户或做域名白名单校验，所以 Host 必须准确：
-
用
$http_host而非$host：保留原始端口（如app.example.com:8443），避免 HTTPS 终止后 Host 缺失端口导致后端鉴权失败； - 若前端部署在子路径（如
https://example.com/admin/），且后端 API 路径也带前缀（/admin/api/），需配合rewrite提前剥离，再用proxy_pass转发，Host 头保持不变即可； - 不要硬编码
proxy_set_header Host example.com，否则所有子域名、测试环境都会被统一覆盖。
跨域调试与 Origin 透传
本地开发时，前端跑在 http://localhost:3000，调生产 API 域名，浏览器自动带 Origin: http://localhost:3000。后端若严格校验 Origin，必须原样透传：
aperture: the L402 aware reverse proxy
下载
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
-
显式转发 Origin 头：
proxy_set_header Origin $http_origin;—— 变量名注意是$http_origin（横线转下划线，全小写）； - 如果后端只允许特定源，Nginx 不能改 Origin（会破坏 CORS 安全机制），只能由后端响应
Access-Control-Allow-Origin； - 预检请求（OPTIONS）不需要转发到后端，可用
if ($request_method = 'OPTIONS') { add_header ...; return 204; }直接响应，减少后端负担。
微前端或多基座架构的 Header 隔离
主应用和子应用可能来自不同团队、不同域名，通过 Nginx 统一路由（如 /app1/、/app2/）。此时需隔离上下文信息：
- 用
map指令提取路径或 header，注入自定义标识：map $request_uri $micro_frontend_id { ~^/app1/ "app1"; ~^/app2/ "app2"; }，再proxy_set_header X-Micro-Frontend-ID $micro_frontend_id;； - 若子应用需携带认证 Token，且主应用已注入到请求头（如
X-Auth-Token），必须显式透传：proxy_set_header X-Auth-Token $http_x_auth_token;； - 避免把所有
$http_*头全量转发，只传业务真正需要的，减少后端解析开销和潜在安全暴露。
WebSocket 实时能力支持
前端用 Socket.IO、SSE 或自研长连接时，HTTP 升级握手依赖两个关键头：
-
proxy_set_header Upgrade $http_upgrade;—— 把客户端的Upgrade: websocket原样带上； -
proxy_set_header Connection "upgrade";—— 注意双引号，这是固定字符串，不是变量； - 这两行必须和
proxy_pass在同一location块内，且不能被其他proxy_set_header覆盖（Nginx 只生效最后一条同名指令）。
本质上，前端架构差异最终都落在请求头行为上。Nginx 的角色就是精准还原或补充这些头，让后端拿到的请求，和用户直接访问后端时一模一样。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
