关闭预加载后，秒开！
不能断定 Chrome “夹带私货”。 代理环境下速度差异更可能来自 Chrome 自身代理连接建立机制与 Firefox 的协议处理方式不同，而非额外的“私货动作”。
最可能的原因：Chrome 的代理连接预检机制
Chrome 在启用代理时，启动或网络变更后会异步进行一个名为 dns-tunnel-check.googlezip.net 的 DNS 查询，用于判断是否需要为预加载功能保留网络可见性。在 NixOS 的代理配置下，这个查询可能因代理路径或 DNS 处理差异而超时，导致初始请求被延迟。
这个机制是 Chrome 预加载（Preconnect / Prefetch）架构的一部分，旨在优化页面加载速度，但在某些代理配置下反而可能成为负担。你可以在 Chrome 设置中尝试关闭 “使用预测服务更快地加载页面”，观察延迟是否消失。
其他值得排查的 Chrome 特有因素
代理连接建立的差异：Chrome 对需要认证的 SOCKS5 代理支持不佳。如果你的代理需要用户名/密码认证，Firefox 可能处理得更流畅。
扩展程序与后台服务：Chrome 的扩展和 Service Worker 可能产生额外网络请求。可通过
chrome://extensions开启开发者模式，检查后台页面的网络活动。用无痕模式（禁用所有扩展）访问 Gmail 是最快的排除方法。连接调度策略：有案例表明，Chrome 在使用
localhost而非127.0.0.1时会对每个请求产生约 300ms 的额外“初始连接”延迟，而 Firefox 没有此问题。类似的主机名解析差异可能在代理环境中被放大。
如何验证是否存在“私货”
如果确实想确认 Chrome 是否在后台发起了额外连接，可以：
开启 Chrome 的
chrome://net-internals/#events，记录一次 Gmail 访问的完整网络事件，观察除了 Gmail 域之外还有哪些请求。检查
chrome://extensions中每个扩展的后台页面网络活动。在 NixOS 层面用
tcpdump或 Wireshark 抓取经过代理的流量，对比 Firefox 和 Chrome 的连接目标差异。
先尝试关闭预测服务，并用无痕模式测试，这两步能快速判断问题是否来自代理预检或扩展干扰。如果无痕模式下依然慢，则更可能是 Chrome 代理栈与你的代理配置存在兼容性问题。