Cloudflare Worker fetch()全局不尊重Cloudflare工作路由

Question

我有一个由Cloudflare代理的web应用程序，在hybrid-app.example上运行

我正在使用Cloudflare工作场所模式在hybrid-app.example/static-content/上托管一个静态站点。这个工人正在*hybrid-app.example/static-content*路线上监听。我可以通过导航到https://hybrid-app.example/static-content/hello.html并从我的静态站点查看正确的内容来验证此工作人员配置是否正确。

我还有第二个Cloudflare工作人员，它使用worker 路由器模式代理从静态站点选择页面到相同域中的虚荣心URL。特别是，此工作人员被配置为在路由*hybrid-app.example/hello*上侦听。在内部，它做了以下工作：

return fetch('https://hybrid-app.example/static-content/hello.html')

但是，当我导航到https://hybrid-app.example/hello时，我看到一个GET请求访问了我的原始服务器。因此，当我在Cloudflare工作者中调用fetch函数时，它解析请求而不与任何其他工作路由检查匹配。在解析之前，除了Fetch API之外，还有其他方法可以强制来自一个cloudflare工作者的请求来检查其他匹配的CF工作路由吗？

Answer 1

这是不可能的；Cloudflare工作人员总是绕过Cloudflare (包括请求被路由到工人的步骤) 对于同一区域中的请求

关于工作人员组合(一个工作人员调用另一个工作人员)：在相同的区域子请求上不可能进行这样的请求链接。相反，我们总是把这些寄到原处。这个限制是为了解决歧义:我们如何知道子请求是“受信任的”，应该直接发送到原点，而不是“不受信任的”，并且应该从一开始就运行所有Cloudflare特性(包括工人)？(请注意，跨区域子请求不存在这种模糊性:从其他区域的角度来看，这样的子请求显然是不可信的。)