Timing-Allow-Origin 必须配置在 Apache 而非前端代码，因为它是服务端响应头，浏览器仅在跨域资源请求启用高精度计时 API 时校验该头以暴露 timing 信息，缺失则 duration 等字段返回 0，且无法通过前端代码伪造或补救。
Timing-Allow-Origin 为什么必须配在 Apache 而不是前端代码里
因为 Timing-Allow-Origin 是一个响应头，且只能由服务端设置；浏览器在发起跨域资源请求（比如前端监控 SDK 加载 https://logs.example.com/collect）时，若启用了 performance.getEntriesByType('resource') 或 navigation 等高精度计时 API，会检查该响应头是否允许暴露 timing 信息。没这个头，duration、connectStart 等字段一律返回 0 —— 前端监控就丢了关键性能数据。
它不能靠 fetch() 的 headers 参数伪造，也不能用 document.addEventListener('readystatechange') 补救，纯服务端治理项。
mod_headers 必须启用且作用域要对
确认 mod_headers 已加载：apachectl -M | grep headers 应输出 headers_module (shared)。若无，需在 httpd.conf 或 apache2.conf 中取消注释：LoadModule headers_module modules/mod_headers.so（Linux）或对应路径下的 DLL（Windows）。
配置必须放在能覆盖目标响应的上下文中：
立即学习“前端免费学习笔记（深入）”；
- 如果监控接口是独立域名（如
logs.yourapp.com），直接在该<virtualhost></virtualhost>内写 - 如果是同域子路径（如
/api/v1/metrics），放在<location></location>块里更安全 - 避免写在
.htaccess—— 多数共享主机禁用Header指令，且性能开销大
Header set Timing-Allow-Origin 的三种写法及适用场景
不要无脑写 Header set Timing-Allow-Origin "*"：该通配符只对不带凭据（credentials: false）的请求生效；一旦前端 fetch 设置了 credentials: 'include'，浏览器会直接拒绝该头，timing 仍不可用。
推荐按需选择：
- 单前端域名（如仅
app.yourapp.com调用）：Header set Timing-Allow-Origin "https://app.yourapp.com" - 多前端域名（含 http/https、www/non-www）：
Header set Timing-Allow-Origin "%{HTTP_ORIGIN}e" env=HTTP_ORIGIN，并确保Origin在白名单内（需配合SetEnvIf判断） - 完全信任的内部监控域名（如所有调用都来自
*.yourapp.internal）：Header set Timing-Allow-Origin "https://*.yourapp.internal"—— 注意 Apache 不支持通配符匹配子域，得用正则 +Header always set配合SetEnvIfNoCase
容易被忽略的两个兼容性坑
第一，Timing-Allow-Origin 必须和 Access-Control-Allow-Origin 同时存在且值一致（或兼容），否则 Chrome 115+ 会静默丢弃 timing 数据 —— 即使控制台不报 CORS 错误。
第二，Apache 默认不继承父级 Header 设置。如果你在 <virtualhost></virtualhost> 设了 Timing-Allow-Origin，但监控接口实际由 PHP-FPM 或 ProxyPass 转发，需显式加 Header always set，否则代理后可能丢失：
ProxyPass /collect http://127.0.0.1:8080/collect Header always set Timing-Allow-Origin "https://app.yourapp.com"
真正难调的是多层代理链路（Nginx → Apache → Node.js），此时 timing 头必须在最终响应生成处设置，中间层只透传不覆盖 —— 很多人卡在这里查三天才意识到 Apache 根本没拿到原始响应体。
