服务对象与地域限制
PuppyIP 仅面向海外合规企业及其授权人员提供服务，不面向中国大陆地区开放或提供代理服务。本服务仅限用于中国大陆境外的合法业务活动，严禁在中国大陆境内使用本服务。
代理 IP 或服务器位于境外，不改变上述限制。不得通过中转、转接、共享或转售向中国大陆境内的最终使用者提供本服务。使用前请阅读用户服务协议。
本文要点
- 会话创建或更新报400，先核网页工具allowed_domains是否落在环境allowed_hosts范围内。
- url_not_allowed看目标主机；url_not_in_prior_context看URL是否通过合资格的会话内容出现。
- API创建环境时省略networking会得到unrestricted；Console创建表单从Limited、未额外放行任何主机开始。
- 根域不会自动放行子域，通配子域也不包含根域；新增网页工具主机同时会向sandbox开放该主机。
先认错误：是会话没建成，还是工具被拒？
先看失败的位置。会话创建或更新返回400，属于配置检查；web_fetch返回url_not_allowed，属于主机范围；返回url_not_in_prior_context，则要查链接的来源。它们不能用同一种“放开网络”解决。
Anthropic在2026年10月7日发布记录中说明了这些变化。范围是Claude Managed Agents的托管执行，当前仍为beta，使用managed-agents-2026-04-01标头；不能直接套到普通聊天、browser use SDK或Amazon Bedrock。
这些是当前官方规则，具体账号何时采用、各会话的实际配置仍需单独确认。本文没有运行真实Agent或调用账号API；先保存现有配置和准确错误，再按下面的对应关系改动。
API和Console默认不同，先把networking写明确
创建环境的API请求如果省略networking，会得到unrestricted。Claude Console的创建表单则从Limited开始，且没有额外允许的主机。相同任务从两个入口创建，不能假设默认网络范围一样。
limited用于只允许列出的目标。完全不设置其他放行字段时，没有主机获准访问，但附到会话的文件、memory stores和GitHub仓库仍然可用。任务只需这些资料时，不必为了网页工具而开放无关网站。
把需要的网络模式显式写进创建请求，并在allowed_hosts里列出任务真正需要的主机。只有无法预先列出目标时，才另行评估unrestricted的风险；它不是修复抓取失败的默认选项。
遇到400，把两张名单和主机写法对齐
启用的网页工具如果设置allowed_domains，其中某项不在环境allowed_hosts范围内，创建会话就会返回400。更新会话加入同样不一致的条目，也会失败。先找出具体哪项越出环境范围。
allowed_hosts使用裸主机名或通配模式，不带协议、端口和路径。example.com只匹配这个根域，不匹配www.example.com；*.example.com覆盖子域，却不包含example.com本身。需要两者时要分别考虑。
假设业务只要访问docs.example.com：若已批准该目标，可把它加入allowed_hosts；若工具名单只是误填，则删掉不需要的allowed_domains条目。选择依据是实际任务范围，不是哪个改法能让错误消失。
会话建好了，为什么搜索或抓取仍没结果？
limited现在也限制运行在Anthropic服务器上的web_search和web_fetch。目标主机不匹配allowed_hosts时，web_fetch把url_not_allowed作为错误结果交给Agent；web_search会省略这些主机的结果。空名单下，两者都不会返回页面或搜索结果。
allow_package_managers和allow_mcp_servers用于sandbox的额外可达范围，不会替这两个网页工具增加主机。需要网页工具访问某网站时，仍要把主机列进allowed_hosts；仅允许安装包或连接MCP并不足够。
另看sandbox自己的请求：在80或443端口因主机未获准而被拒，会收到注明被阻止主机的403。这个403与会话400、web_fetch工具错误分开处理，先确认究竟是哪一个调用发出的请求。
域名已允许，还要让URL通过正确来源出现
web_fetch现在只抓取已经通过合资格内容出现在会话里的URL，例如用户消息的文本、web_search结果，或此前web_fetch返回的页面。这是另一道检查：主机获准访问，不等于任意链接都可以抓取。
链接如果只出现在Claude自己的输出、系统提示、附加文档，或者bash、read、MCP工具输出中，不算满足条件。此时工具会返回url_not_in_prior_context；反复修改域名名单并不能补足来源。
假设负责人批准读取某个公开文档链接，可把准确URL写进user.message事件的文本，再让Agent抓取。这个例子说明如何提供已批准的目标，并非让不可信网页替你授权，也不代表私有资料可以随意发送。
改完怎样确认修对了：逐层看结果
先确认创建或更新不再因名单矛盾返回400，再看目标主机是否匹配。若还有url_not_in_prior_context，就核URL进入会话的方式；若失败来自sandbox403，则检查那个请求的主机。一次只处理对应层，便于确认原因。
允许网页工具访问一个主机，也会向sandbox开放它。主机获准不表示只读：代码可能上传资料、调用接口或改变外部状态。只放行必需主机，并为业务动作另外设置合适权限，不能靠“请只读取”代替控制。
最后检查工具是否拿到所需页面或有效搜索结果，以及内容是否回答了当前任务。会话能建立、错误消失或HTTP成功，都不单独证明答案正确；确认有效后再保存这次配置与结果，便于后续排错。
资料来源
常见问题
只处理附加文件，还必须开放网页工具吗？
不必为没有网页需求的任务增加网站权限。官方说明limited且未额外放行主机时，附到会话的文件、memory stores和GitHub仓库仍可用；先核任务是否真的需要搜索或抓取外部页面。
这些网络规则能替代网页工具自己的过滤吗？
不能把它们当作同一个设置。环境决定网络范围，工具的allowed_domains或blocked_domains还能进一步收窄搜索与抓取目标；受limited环境约束时，工具设置也须与环境允许范围一致。
用了self-hosted环境，就能随便抓任何URL吗？
官方仅说明self-hosted环境和unrestricted网络模式不会以环境网络名单限制这些网页工具。工具本身的域名过滤和Managed Agents的URL来源检查是另外的规则，不能由执行地点推断任意链接都被允许。