proxy_pass 不在微前端沙箱拦截范围内，因其是 Nginx 等服务端反向代理指令，而沙箱仅隔离浏览器端 JS 执行环境；沙箱可拦截子应用非法跨域请求、全局变量篡改及动态代码绕过，需结合客户端封装与服务端网关管控。

微前端沙箱中并不存在 proxy_pass 这一概念——它属于 Nginx 反向代理层的配置指令，运行在服务端，而微前端沙箱（如 ProxySandbox、SnapshotSandbox）是浏览器端的 JavaScript 执行环境隔离机制，两者处于完全不同的网络层级和运行时域。

为什么 proxy_pass 不在沙箱拦截范围内

proxy_pass 是服务端行为，由 Nginx、Traefik 或网关组件解析和执行，发生在请求抵达浏览器之前或响应返回之后。微前端沙箱只控制子应用脚本对 window、document 等全局对象的访问与修改，无法感知、更无法干预服务端的路由转发逻辑。

子应用代码里写 fetch('/api/user')，最终是否被 Nginx 用 proxy_pass http://backend 转发，取决于：

• 主应用配置的请求基地址（如 axios.defaults.baseURL = '/gateway'）
• Nginx 的 location 规则与 rewrite 配置
• 浏览器同源策略与 CORS 响应头

真正需要拦截的“非法代理行为”是什么

用户实际关心的，往往是子应用试图绕过主应用约定、发起未授权的跨域请求或篡改请求目标。这类行为发生在客户端，可被沙箱机制协同治理：

PigX UI 前端开发

PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。

下载

立即学习“前端免费学习笔记（深入）”；

• 子应用直接写 fetch('https://evil.com/api') —— 属于非法跨域调用，应由请求守卫拦截
• 子应用动态拼接 URL：fetch(window.API_HOST + '/data')，而 window.API_HOST 被恶意重写 —— 属于全局变量污染，需 Proxy 沙箱 + Setter 审计
• 子应用通过 eval 或 Function('return fetch(...)')() 绕过封装 —— 沙箱需禁用危险构造函数

如何在客户端“过滤”非法请求目标

这不是靠“过滤模块”被动筛选，而是通过主动封装 + 沙箱约束构建安全边界：

• 主应用统一提供 request() 方法，内部校验 URL 是否匹配白名单正则（如 ^/api/|^/gateway/），拒绝非法 host
• 在 ProxySandbox 的 set trap 中拦截对 window.API_HOST 等敏感字段的赋值，结合闭包维护只读白名单，非法值直接忽略或报错
• 利用闭包封装请求 SDK，将允许的后端域名列表、token 注入逻辑、错误重试策略全部封闭在私有作用域，防止子应用覆盖或读取
• 沙箱启用时禁用 eval、Function 构造函数、with 语句，从执行源头阻断动态绕过

服务端配合才构成完整防线

客户端拦截是第一道防线，但不可替代服务端管控：

• Nginx 层配置 valid_referers 和 if ($invalid_referer) { return 403; }，拒绝非主应用域名发起的直连请求
• 网关校验请求头中的 X-SubApp-ID，确保每个子应用只能访问分配给它的 API 分组
• 所有 proxy_pass 目标必须显式声明、静态配置，禁止运行时拼接或反射式转发