浏览器时区与 IP 定位：一个风险信号的比较
浏览器时区和由 IP 推断的时区衡量的是不同的事。在把不一致当成 VPN 结论之前，先比较两者各自能证明什么。
浏览器报告 Europe/London，而 IP 数据库把该请求归到 America/New_York。这是两个观测之间的分歧，值得记录下来。它不是访客使用 VPN 的证明，而把它当作证明正是大多数实现出错的地方。下面的比较把这两个取值以及各自的失效方式分开处理。
两个归属不同的观测
浏览器取值是一种设置：操作系统或用户为格式化日期而选择的时区。数据库取值是附在 IP 网段上的估算，由把地址块映射到地点的服务商生成。两者都不是关于访客身处何处的经认证陈述，也都不知道请求走了哪条网络路径。
由于归属不同，这两个取值可能因为与隐私工具毫无关系的原因而分歧。保留家乡时区的旅行者、固定在总部时间的公司笔记本、带区域出口的卫星链路，或一行过期的数据库记录，都会造成不一致。
每个取值实际是如何产生的
浏览器可以用以下方式读取其解析后的时区：new Intl.DateTimeFormat().resolvedOptions().timeZonenew Intl.DateTimeFormat().resolvedOptions().timeZone
，它返回由格式化器设置推导出的 IANA 标识符。它不申请定位权限，也不查询 GPS。在服务器端，从可信的代理配置中解析客户端地址，再用经批准的服务商查询。访客提供的转发头并不自动就是该地址。vpnDetected把两个观测保存为独立字段，并记录观测时间和查询结果。当计算只是一次时区比较时，把派生字段命名为
vpnDetected
| ，等于把结论烤进测量，也会让后续复核更难。 | 一致与不一致各自能证明什么 |
|---|---|
| 观测 | 仍未解决的部分 |
| 报告的时区不同 | 旅行、保留的设置、企业网关、代理或数据库错误都可能造成这种情况。 |
| 报告的时区相同 | VPN 出口可能就在用户所在时区，因此一致并不能确立直连。 |
有一个取值缺失或无效
比较无法进行，这既不是一致也不是不一致。
不对称性比表格显示的更重要。不一致有许多无辜解释，而一致至少有一种有罪的解释，因此任何方向都不支持一刀切的规则。服务商自己的精度说明也描述了有限的精度和缺失的数据，并指出匿名化服务暴露的可能是其服务器位置而非用户位置。
这就是为什么该信号应进入带记录原因和显式未知状态的风险评分，而不是进入控制访问的布尔值。
UTC 偏移不是捷径
用偏移代替时区标识符来比较并不能修复推断。两个不同时区可能在一年的一部分时间共用同一偏移，而同一时区也可能在夏令时边界改变偏移。若某项功能确实需要偏移来做排期，应针对具体时刻计算，而不是存下一个数字并把它当作身份证据重复使用。
字符串比较有自己的陷阱：同一时区的两种拼写或旧别名，虽然描述同一设置，作为文本却不同。应校验标识符，并通过平台的时区处理来比较，而不是匹配原始字符串。
拦截还是评分：有意识地选择响应