服务对象与地域限制
PuppyIP 仅面向海外合规企业及其授权人员提供服务，不面向中国大陆地区开放或提供代理服务。本服务仅限用于中国大陆境外的合法业务活动，严禁在中国大陆境内使用本服务。
代理 IP 或服务器位于境外，不改变上述限制。不得通过中转、转接、共享或转售向中国大陆境内的最终使用者提供本服务。使用前请阅读用户服务协议。
本文要点
- 适用路径是Worker发起子请求，目标为Cloudflare代理且使用BYOIP的主机名；并非所有Worker请求或所有403。
- CF-Worker与cf.worker.upstream_zone会保留，帮助同zone和跨zone子请求一致地进行安全规则判断。
- 受影响目标zone的Bot信号反映原始终端用户连接，包含bot score、verified bot与JA3/JA4，而非Cloudflare内部连接。
- 改进自动生效、无需改配置；BYOIP本身仍为Enterprise服务，接入资格与合同要另核。公告没有公布费用或逐地区上线时刻。
- 仍报403时，先对照已有请求、规则动作与源站证据；不要以关闭WAF、伪造请求头或轮换代理代替定位。
先看请求是否经过这条BYOIP路径
Cloudflare在2026年10月13日公告：Worker子请求访问一个由Cloudflare代理、使用Bring Your Own IP（BYOIP）的主机名时，现在会被识别为Cloudflare到Cloudflare的流量。子请求就是Worker处理一次请求时，再向另一个地址发出的请求。
BYOIP让组织把自己的IP前缀交由Cloudflare宣告和承载服务，而不是改用Cloudflare拥有的地址。这里要核对的是目标主机名是否真的使用BYOIP；仅仅拥有一个代理IP、配置Worker，或看到Cloudflare的403，都不足以匹配这次变化。
此前部分这样的子请求会丢失Worker上下文及原始客户端信号，被当作外部互联网流量。安全规则可能因此判断异常，Bot Management可能评估Cloudflare内部连接，受影响请求可能出现误报403。公告说的是部分路径的问题，没有声称全部403已解决。
保留Worker来源，也保留真正的客户端信号
修复保留CF-Worker请求头与cf.worker.upstream_zone字段，用于一致处理同zone和跨zone的子请求。zone指Cloudflare中的域名配置区域；两个zone之间的调用，也不应因为目标使用BYOIP而丢失Worker上下文。
目标zone的Bot Management字段现在反映原始终端用户连接。规则表达式中的cf.bot_management.score、cf.bot_management.verified_bot、cf.bot_management.ja3_hash与cf.bot_management.ja4，分别对应bot评分、已验证bot状态，以及JA3/JA4客户端TLS指纹。它们不再代表受影响路径中的Cloudflare内部连接。
例如，一个合法用户先访问Worker，Worker再读取另一zone的BYOIP域名，这是未执行的示例。目标仍能知道请求经过Worker，同时依据原始用户的Bot信号判断；“来自Worker”和“代表终端用户连接”并不矛盾。修复纠正判断输入，不保证用户一定获得高分或被放行。
自动修复，不等于免费开通BYOIP
已在受影响路径上的客户无需为这项改进修改配置。但BYOIP概览明确标为Enterprise-only；首次接入前，仍须由账号团队确认合同包含BYOIP及所需服务配置。公告没有给出新增收费或免费的承诺，费用应按实际合同确认。
接入资格也不只是“有IP”。官方要求IP前缀登记、匹配的IRR路由记录、准确的RPKI路由授权，以及所有权验证通过。其当前入门流程只适用Cloudflare的AS13335；使用自己的ASN或接入Magic Transit，要走相应的其他流程。不要为验证这个修复临时宣告生产前缀或修改DNS。
Bot字段文档的保留规则有“Bot Management实际生效”的条件，计划页也把Bot Management列为Enterprise项目。不能从BYOIP资格推定目标zone已获得全部Bot功能。公告没有逐国家开放清单、准确上线时刻或个人账号验收结果，本文也未执行账号请求。
仍有403，按原调用链做只读对照
第一步，让维护者核对已有部署记录：哪个Worker发起请求、实际目标主机名、目标zone，以及该主机名是否使用Cloudflare代理的BYOIP地址。保留发生时间、目标路径和已知请求标识，先确认故障确实走过公告描述的链路。
第二步，对照已有请求和安全日志中可读的Worker上下文、Bot信号及实际命中规则。记录真正的字段值和规则动作；字段不可见时写明证据缺口，不用空白推断评分为零，也不据此判定修复未生效。不同字段对应规则表达式或Workers对象，交接时注明读取位置。
第三步，用最后一次成功请求和当前失败请求比较目标、身份授权、规则动作与源站结果。即使上下文已保留，Access授权、其他WAF规则或源站本身仍可能拒绝请求。若证据明确指向托管WAF误拦截，可继续阅读已有WAF排查指南；不要直接关掉整个规则集或改用另一出口赌结果。
给维护者一个能继续查的结论
交接应说明：是否确认BYOIP目标、可读Worker上下文与Bot字段、实际403来源、已命中的规则，以及仍缺哪项证据。先移除日志中的凭据和业务敏感内容。只有已有日志不足、仍需复现时，再由有权限的维护者安排获准测试环境中的只读调用；本文没有替读者测试。
Cloudflare提供的是这条路径的上下文修复，不是账号授权、风控放行或网络出口服务。若目标没有使用BYOIP，或证据指向完全不同的403来源，就沿对应故障继续查；不能因为同样出现403便把两次故障归为同一原因。
资料来源
常见问题
Workers代码里的Bot字段也叫cf.bot_management吗？
不是同一访问形式。规则表达式使用cf.bot_management.score等名称；Workers在request.cf.botManagement对象上使用score、verifiedBot、ja3Hash、ja4。检查时保留实际读取位置，避免把两套字段名直接互换。
手动补一个CF-Worker请求头就能获得同样效果吗？
不能据此确认。公告描述的是Cloudflare保留内部Worker上下文与原始客户端信号，且无需客户改配置；只出现一个同名请求头，不能证明完整上下文、Bot信号或请求授权正确。
普通HTTP或SOCKS代理IP属于这里的BYOIP吗？
仅有可使用的代理地址不等于拥有可接入Cloudflare的IP前缀。BYOIP需要合同服务配置及登记、路由授权和所有权等检查；这次修复也不改变代理使用资格或目标网站的访问规则。
现在可以撤掉以前为403设置的例外吗？
不要只凭公告撤改生产规则。先让负责人确认旧例外针对什么故障、当前上下文与规则证据是否对应，再在获准环境验证原来的合法调用和必要安全检查。没有这些证据，不能宣称旧例外已经不需要。