为何伪造浏览器时区后真实时区仍被服务器检测到？

服务器检测客户端时区的其他途径 #

你已经通过重写Date类、Intl.DateTimeFormat相关方法伪造时区，但仍被服务器识别出真实时区，说明网站还利用了以下未被覆盖的检测方式：

1. 区域语言信息关联时区 #

服务器可通过navigator.language/navigator.languages返回的区域语言（如zh-CN对应东八区、en-US对应西五/西四区），结合常见区域-时区映射表推测真实时区。这类信息通常不会被常规的时区伪造脚本覆盖。

2. CSS 时区媒体查询检测 #

部分网站会通过动态创建样式元素，利用CSS的time-zone媒体查询（如@media (time-zone: "Asia/Shanghai")），再通过getComputedStyle读取生效规则，将真实时区信息传递给服务器。这种检测方式绕开了JavaScript的Date/Intl API。

3. WebRTC 时间差计算时区 #

WebRTC可通过NTP服务器获取精准UTC时间，同时读取客户端本地系统时间（该时间可能未被你的Date伪造逻辑覆盖），服务器通过两者的时间差计算出真实时区偏移量。很多反代理检测站点会用WebRTC获取这类底层系统信息。

4. 存储残留数据读取 #

如果之前访问过目标站点或关联站点，LocalStorage、SessionStorage或Cookie中可能存储过真实时区信息，服务器直接读取这些残留数据，无需重新检测。

5. 请求头区域信息推断 #

Accept-Language请求头中的区域标识（如zh-CN）会被服务器用来关联对应时区；部分浏览器或扩展还会自定义发送Time-Zone类请求头，直接泄露时区信息。

6. 第三方脚本追踪 #

站点引入的第三方分析、广告脚本可能自带独立的时区检测逻辑，这些脚本不受你的Tampermonkey脚本覆盖，会将真实时区上报给服务器。

针对当前场景的排查与解决方向 #

• 拦截WebRTC：在脚本中禁用window.RTCPeerConnection，阻止其获取系统时间与IP信息。
• 覆盖CSS媒体查询读取：重写getComputedStyle方法，伪造时区相关的CSS规则返回结果。
• 清理存储残留：手动清除目标站点的LocalStorage、SessionStorage和Cookie，避免旧数据被读取。
• 修改请求头：通过Tampermonkey或浏览器扩展修改Accept-Language头，使其区域标识与伪造时区匹配；拦截并修改自定义的时区请求头。
• 屏蔽第三方脚本：在脚本中阻止站点加载第三方分析、广告类脚本，切断其信息上报路径。

内容的提问来源于stack exchange，提问作者user30152918