服务对象与地域限制
PuppyIP 仅面向海外合规企业及其授权人员提供服务，不面向中国大陆地区开放或提供代理服务。本服务仅限用于中国大陆境外的合法业务活动，严禁在中国大陆境内使用本服务。
代理 IP 或服务器位于境外，不改变上述限制。不得通过中转、转接、共享或转售向中国大陆境内的最终使用者提供本服务。使用前请阅读用户服务协议。
本文要点
- getStats新增连接和数据报统计；supportsReliableOnly始终返回false，表示尚无HTTP/2上的WebTransport支持。
- 把ReadableStream作为请求体的流式上传，仅在Nightly启用，不能算正式版158的默认能力。
- 早到WebSocket消息的修复改善Network Monitor记录，不证明代理或实际连接已修好。
- deliveryType本次最初支持cache；桌面158要求Windows 10+、macOS 10.15+或符合要求的GNU/Linux环境。
这次新增的是统计，还是新的连接方式？
Firefox 158于2026年10月13日首次提供给桌面Release渠道用户。MDN的开发者说明将158标为Stable，并列出WebTransport.getStats()新增支持；它返回底层连接及数据报的统计，可帮助开发者观察已有传输。
WebTransport可以让网页与服务器建立数据传输会话。能读取统计，不等于新增一条可用连接路线：本次说明没有承诺自动修复失败的握手、代理连接或服务端配置。统计字段的单位与权限条件，应另看对应API文档，不能按接口名称猜数值。
supportsReliableOnly为false，到底缺哪一种能力？
同一页新增了WebTransport.supportsReliableOnly静态属性，用来判断浏览器是否支持只使用可靠传输的WebTransport会话，例如HTTP/2。Firefox目前尚不支持HTTP/2上的WebTransport，因此该属性始终返回false。
这个false不是“完全不支持WebTransport”，也不是一次连接失败的诊断结果。它说明的是这项传输能力，不证明某个服务器、出口或网络一定可用。
举个未执行的兼容性设计例子：如果服务依赖HTTP/2上的WebTransport，Firefox 158仍不能靠这次更新满足条件。开发者需要保留已经验证可用的其他应用传输方案，而不能把getStats的出现当成自动回退已经做好。
流式上传写在158文档里，为什么不能当正式版功能？
MDN在Experimental web features下列出了Streaming request bodies，并明确写为Enabled in Nightly only。它允许将ReadableStream作为Request()或Window.fetch()的请求体，逐段上传，而不是等整个请求体准备完。
页面列出的实验偏好是dom.fetch.streaming_upload，但渠道条件同样重要。正文出现“158”或列出偏好名，不代表正式版用户默认可用；不能仅让读者改变一个设置，就保证正式版具备这项Nightly能力。
这项限制针对流式请求体，不是对所有文件上传的统一结论。发现上传问题时，先分清应用是否真的使用ReadableStream请求体，再核对客户端渠道和报错；本文没有在用户账号或浏览器上执行上传测试。
WebSocket消息补抓到了，实际连接也修好了吗？
正式发布说明修复了Network Monitor可能漏掉的WebSocket消息：这些消息在连接刚建立后立即到达，开发者面板以前可能没有记录。改进落在调试工具的可见记录，不是宣布WebSocket连接、代理或服务器传输全部得到修复。
需要复查时，可先在自己的测试页面打开Network Monitor，再建立测试连接，比较面板记录与应用实际收到的消息。保存浏览器版本、开始记录的时间和脱敏报错，能帮助区分“面板没记到”与“应用没收到”。这是一条检查建议，并非本文已替你执行。
deliveryType的cache，能说明多少缓存信息？
Firefox 158开始支持PerformanceResourceTiming.deliveryType属性，最初支持的值是cache，用来标识资源来自缓存；正式发布说明对应的是HTTP缓存交付。不要把这一项扩展成所有交付类型、代理缓存或CDN命中都已完整可见。
读到cache可以提供资源交付来源的线索，却不能单独证明响应一定更快、服务端没有问题或本轮网络链路已通过。检查具体资源时，把它与应用现象和其他已有记录一起看；不能把没有cache值直接写成所有缓存都未命中。
先查桌面系统和渠道，再安排兼容性检查
官方158系统要求列出Windows 10或更新版本，以及macOS 10.15或更新版本；Mac硬件可为Intel x86或Apple silicon。这里讨论的是桌面Release版本，不能据此推定Android、iOS或ESR具有完全相同的能力与更新时间。
GNU/Linux上游构建要求glibc 2.17+、GTK+ 3.14+、libglib 2.42+、libstdc++ 4.8.1+及X.Org 1.0+；arm64分别要求glibc 2.28+和libstdc++ 6.0+。发行版打包可能有不同要求，页面列出的推荐组件也不能当成全部强制条件。
先记录实际Firefox版本、Release或Nightly渠道、操作系统与架构，再检查目标应用所需的API和服务器传输条件。正式版发布日不等于每台机器已经更新，也不替代目标应用自己的支持说明。
再分别验证可建立的会话、能够读取的统计、调试面板记录和流式请求体。一次只改变一个条件，记录预期与实际结果；本次更新没有给出这些组合的实测性能或所有网络环境下的成功保证。
资料来源
常见问题
getStats的结果能直接按固定单位比较吗？
这三份已读发布与系统文档没有列出全部统计字段、单位或权限规则，不能补造统一换算表。先查看对应API的字段定义，再确定采样时点和比较口径；接口存在也不等于已有连接成功。
Android、iOS和ESR会在同一天拥有完全相同的能力吗？
不能由桌面158的Release记录推定。移动版、ESR和Nightly应核对各自版本与渠道说明；本文未完成这些客户端的逐项能力验收，也未验证个人设备何时收到更新。
更新Firefox后，第三方工具就一定支持它了吗？
不一定。浏览器新API或调试修复没有替第三方产品宣布客户端支持。仍需查看目标工具自己的支持说明与入口条件，不把浏览器版本变化当成第三方兼容承诺。
为了这次更新，必须重新配置代理吗？
这些发布条目没有宣布必须调整代理设置。出现实际故障时，应按具体连接方式和原始错误排查；新增统计或补齐消息记录本身，不是更换出口或改代理协议的依据。