chrome默认启用ping属性但可手动禁用，firefox默认彻底禁用且不可开启，safari从未支持；实际使用中易受协议限制、网络拦截等影响，不推荐用于生产环境。
Chrome 的 ping 属性默认是启用的，但可被手动禁用
Chrome 当前（截至 2026 年 4 月）仍默认支持 HTML 中的 ping 属性，比如 @#@#@#@#@#@#@#@#@#@0。它不是因“隐私设置”自动关闭的，而是作为一项独立功能存在——既没被默认关掉，也没在设置界面提供开关。是否生效，取决于你有没有主动干预。
- 打开
chrome://flags/#disable-hyperlink-auditing，若该实验性标志设为Disabled，则ping功能被强制关闭；设为Default或Enabled（后者已不显示），即保持启用 - 新版 Chrome（如 142+）不再在 flags 页面显式列出该选项，但它底层仍受同一机制控制；未手动修改过，就默认开着
-
ping请求走的是独立的后台 HTTP POST，不携带 Cookie、不触发 CORS 预检，也不受document.referrer策略影响——这点常被误认为“被隐私模式拦截”，其实不是
Firefox 默认禁用 ping，且不提供用户开关
Firefox 是目前主流浏览器中唯一默认彻底禁用 ping 的。你进 about:config 查 browser.send_pings，值一定是 false，而且这个偏好项是只读的，无法通过 UI 或配置文件开启。
- 这不是 bug，是 Mozilla 明确的隐私立场：认为该功能“几乎无正当用途，却有明确滥用风险”
- 即便你用 JS 动态创建带
ping的<a></a>并调用.click()，Firefox 也完全忽略该属性 - 所以如果你在做跨浏览器行为测试，别指望 Firefox 会发出任何
ping请求——它压根不解析这个属性
为什么你的 ping 请求没发出去？常见干扰点
即使 Chrome 启用了 ping，实际请求也可能静默失败，原因往往和“隐私设置”无关，而是更底层的限制或误用。
- 目标 URL 必须是
http://或https://协议，data:、javascript:、file://等协议直接被忽略 - 如果页面本身是
file://协议打开的（比如双击本地 HTML 文件），Chrome 会直接屏蔽所有ping请求，控制台无提示 - 目标服务器返回非 2xx 状态码（如 404、503），Chrome 不重试，也不报错，请求就“消失”了
- 某些企业网络或代理设备会主动过滤带
Ping-From/Ping-To头的请求，这类拦截在开发者工具 Network 面板里可能根本看不到该请求
安全警告：别在生产环境依赖 ping
这不是一个推荐用于业务逻辑的功能。2025 年已有公开 DDoS 攻击案例，正是利用 ping 属性 + 动态脚本批量触发，绕过常规请求节流。Chrome 计划在未来版本移除它，Firefox 已弃用，Safari 从未支持。
- 它无法被 JavaScript 捕获或监听成功/失败，调试成本高
- 没有 Promise、没有回调、不能 abort，属于纯“fire-and-forget”黑盒行为
- 如果你真需要链接点击上报，用
fetch()或Beacon API（navigator.sendBeacon()）才是现代、可控、可测的替代方案
ping 能开能关，但关了没人知道；开了也容易被网络层吃掉；而真正要命的是——它正站在淘汰队列最前面，连错误提示都懒得给你留。
