MCP Fetch 2026 更新后 localhost 被拒绝？排查指南

判断框｜适合：升级 MCP Fetch 后，本机或内网请求突然失败、且需要确认是预期拦截还是服务故障的开发者。先检查目标最终解析到的 IP；若它不是公网可路由地址，这通常是安全保护而非服务器异常。只有在可信、隔离的测试环境确实要访问本机服务时，才添加 --allow-private-ips，并在测试结束后恢复默认限制。

这篇指南适合用 AI Agent 调试本地 Web 应用的测试人员，也适合负责 MCP Server 网络边界的平台工程师。
如果测试任务不必访问开发者电脑上的服务，优先改用隔离测试环境，不要为省一次部署而扩大 Fetch 进程的网络访问范围。

最后更新于 2026 年 10 月 13 日；核对了官方 v1.0.0 发布记录、Fetch 更新记录与当前 Fetch README。截至核对时，Fetch 对应的 Python 包版本为 2026.10.10；更新后的默认行为是拒绝解析到非公开地址的请求，并对重定向请求逐跳检查。

先判断：被拒绝的地址是不是本来就不该访问

为什么更新后 localhost 会失败？因为 localhost 通常解析到回环地址，而回环地址只指向运行请求的那台机器；它不是公网目标。更新后的 Fetch 默认拒绝回环、私有、链路本地及其他非全球可路由地址，涵盖 IPv4 和 IPv6。域名只要有一个解析结果落入这些范围，也可能被拒绝。

这会造成一个常见误判：本机浏览器能打开开发服务器，但 Fetch 返回拒绝信息，于是团队怀疑服务端口没启动。实际上，两种请求可能来自不同机器、容器或网络命名空间；浏览器成功只能证明浏览器所在环境能够访问，不能证明运行 MCP Fetch 的进程也能访问。

识别错误时，先看 Fetch 报错中列出的地址，再确认请求运行环境。IPv4 私有地址常见范围是 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16；回环范围是 127.0.0.0/8。IPv6 还要留意 ::1、唯一本地地址 fc00::/7 和链路本地地址 fe80::/10。这些范围可对照 IANA IPv4 特殊用途地址登记表、IANA IPv6 特殊用途地址登记表及 RFC 1918 私有网络地址说明。

排查 localhost 时，什么才算有效证据？使用运行 Fetch 的同一台主机、同一容器或同一网络命名空间发起请求，并查看本机请求记录与服务监听状态。模型生成了一个看似正确的 URL，不等于该地址真实可达，也不能代替 DNS 和路由检查。

逐跳检查：公开网址也可能转入内网

公共网页跳转后，会不会也被拦截？会。原始 URL 是公网地址，并不保证后续请求仍然指向公网；如果网页返回重定向，下一跳解析到回环、私有或元数据地址，Fetch 会在该跳拒绝请求。README 也说明检查适用于重定向以及 robots.txt 请求。

定位时，不要只反复测试最初的页面地址。按请求链记录每一跳的目标主机、响应状态和解析结果；如果错误中出现被拒绝的 IP，就把它与对应跳转目标配对。若代理负责解析域名，还要确认 Fetch 进程自身是否能解析同一主机，不能把代理端的解析结果误认为 Fetch 已经验证过。

⚠️ 一个看起来公开、可信的 URL，仍可能跳转到不应访问的内网目标。排查重定向是为了找出触发拦截的位置，不是为了绕过这条保护。

同一个域名为什么有时能抓、有时不能？检查完整 DNS 结果，而不只是一次查询返回的首个 IP。负载均衡、分区域解析或解析记录变化，都可能让请求落到不同地址；如果其中一个结果属于受限范围，拒绝行为可能随解析结果变化。Fetch 的实现会检查主机解析到的地址，具体地址类别可在官方 Fetch 源码中的地址校验逻辑中复核。

不过，默认拒绝不等于完整的 SSRF 防护。官方说明列出了两个重要边界：DNS 重新绑定可能发生在检查与连接之间；若域名只能由代理解析、Fetch 自身无法解析，Fetch 就无法按同一种方式检查它。涉及服务器端 Agent 时，可结合 MCP 官方安全建议设置网络出口策略，不要把 Fetch 的默认拦截当成网络隔离的替代品。

五步排查：从请求环境到重定向记录

按下面顺序操作，能先区分“服务没启动”“网络环境不通”和“安全规则主动拒绝”，避免上来就启用例外。

1. 固定请求发起位置。确认实际运行 Fetch 的进程属于本机、容器、远程主机还是其他隔离环境，并确保后续测试从同一环境执行。
2. 核对报错中的拒绝地址。如果错误信息给出被拒绝的 IP，先判断它是回环、私有、链路本地、元数据还是其他特殊用途地址；不要只看 URL 的域名部分。
3. 验证开发服务监听状态。查看服务是否运行、监听在哪个地址和端口，并从 Fetch 所在环境发起可信的本机请求。若服务只监听另一网络接口或仅对主机可见，容器内请求失败可能与 Fetch 的地址保护无关。
4. 拆开重定向链。逐一检查原始 URL、每个 Location 目标及对应解析结果，定位首次进入受限地址范围的请求。不要因起始页面是公网地址就跳过这一项。
5. 核对 DNS 与代理配置。比较 Fetch 运行环境中的解析结果和代理设置；查看是否有 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 或 NO_PROXY 影响请求路径。官方 README 说明 Fetch 支持代理配置，并会读取这些环境变量。

受控例外：确实需要访问本机服务时

如何让 Fetch 访问本地开发服务器？官方提供的启动参数是 --allow-private-ips，放在服务器配置的 args 列表中。它是 Fetch 进程的启动选项，不是单次工具调用的参数；应以官方配置说明核对具体客户端配置格式。

例如，采用 uvx 启动时，配置形式如下：

{
  "mcpServers": {
    "fetch": {
      "command": "uvx",
      "args": ["mcp-server-fetch", "--allow-private-ips"]
    }
  }
}

重要边界是：这个选项会关闭 Fetch 对私有地址的默认保护，不是只给 localhost:某个端口 开一条精细白名单。配置影响的是该 Fetch 进程可处理的请求范围，因此应把它限制在专用、可信的测试任务中；不要把带例外的配置复用到面向不可信输入的 Agent 或共享环境。

• [ ] 测试确实必须访问本机或内网服务，且没有更窄的替代方案。
• [ ] MCP Fetch 运行在可信、隔离的测试环境中，Agent 工具调用不会被不可信输入随意驱动。
• [ ] 已确认该启动选项作用于 Fetch 进程，而非单个 URL 或单个端口。
• [ ] 测试结束后移除 --allow-private-ips，重启 Fetch，并确认默认限制已恢复。

如果不能勾选以上各项，先不要启用例外。可将应用部署到受控测试环境，让 Agent 访问测试环境中的服务，而不是把开发者工作站的局域网直接暴露给 Fetch。

方案对照：按风险与排障成本选择

下面的评分是我们按“隔离程度、操作成本、是否需要访问本机服务”作出的定性判断，不是本站实测或性能测量。地址分类及参数名称以官方 README、源码和 IANA 登记表为准。

对以调试本地 Web 应用为主的团队，兼容验收时应把“默认拒绝是否符合预期”和“例外是否在测试后撤销”作为两项不同检查，不要把升级后偶发的访问成功当成风险已消失。任务涉及 AI Agent MCP Server 的网络边界时，也应把进程启动参数、代理路径和测试环境分别记录，方便下次升级复核。

如果当前方案是让 Agent 直接访问开发者电脑，它的真实短板通常是网络边界与个人工作站耦合、重定向或 DNS 问题难以复现、以及临时放开的权限容易遗留；若再改用共享远程主机，隔离配置和环境维护也会成为额外工作。需要临时且可单独管理的 Mac 测试环境时，可以先了解 zekmac 的 Mac 环境，再通过使用帮助和方案价格判断是否适合当前测试周期。租赁 Mac 并不会自动解决网络隔离问题；仍需按测试任务配置访问范围。长期稳定重负载或依赖特定物理接口的工作，则更适合评估自购设备和本地部署方案。