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 转发，取决于：
PigX UI 前端开发
下载
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
- 主应用配置的请求基地址（如
axios.defaults.baseURL = '/gateway'） - Nginx 的 location 规则与 rewrite 配置
- 浏览器同源策略与 CORS 响应头
真正需要拦截的“非法代理行为”是什么
用户实际关心的，往往是子应用试图绕过主应用约定、发起未授权的跨域请求或篡改请求目标。这类行为发生在客户端，可被沙箱机制协同治理：
- 子应用直接写
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 的
settrap 中拦截对window.API_HOST等敏感字段的赋值，结合闭包维护只读白名单，非法值直接忽略或报错 - 利用闭包封装请求 SDK，将允许的后端域名列表、token 注入逻辑、错误重试策略全部封闭在私有作用域，防止子应用覆盖或读取
- 沙箱启用时禁用
eval、Function构造函数、with语句，从执行源头阻断动态绕过
服务端配合才构成完整防线
客户端拦截是第一道防线，但不可替代服务端管控：
- Nginx 层配置
valid_referers和if ($invalid_referer) { return 403; }，拒绝非主应用域名发起的直连请求 - 网关校验请求头中的
X-SubApp-ID，确保每个子应用只能访问分配给它的 API 分组 - 所有
proxy_pass目标必须显式声明、静态配置，禁止运行时拼接或反射式转发
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
