VPN DNS 泄漏检查：团队使用前后要确认的客户端设置
团队成员连接 VPN 后，网页能打开，并不代表域名查询也经过了预期的保护路径。做 VPN DNS 泄漏检查，要确认连接前后的解析出口、客户端分流规则，以及浏览器是否单独处理 DNS。团队应统一检查步骤，而不是要求所有人得到完全相同的检测结果。
检查前：先记录环境，再确认客户端设置
DNS 负责把域名转换为可访问的目标。如果查询仍交给本地网络的解析服务，即使部分访问流量经过 VPN，也可能暴露查询线索。不过，检测页出现陌生地区或不同服务商，并不能单独证明泄漏，还要结合所选线路、网络环境和分流方式判断。
- 从下载页面获取 RedGate VPN 客户端，确认系统与应用版本，并完成必要的系统授权。使用订阅的团队成员，应通过客户端提供的入口导入，不在群聊中公开订阅内容。
- 记录当前使用的是办公 Wi-Fi、家庭网络还是移动网络。断开 VPN 后打开 DNS 检测页面，完成一次完整测试，保存时间、解析服务商与地区信息作为基线。
- 查看客户端是否提供 DNS 保护、连接中断保护或类似选项；有则阅读说明并按团队要求开启，没有则不要假定默认具备。
- 记录浏览器安全 DNS、系统加密 DNS及其他网络过滤工具的状态。不要为了让结果一致，就直接关闭团队强制启用的安全功能。
连接后：用相同条件复测并定位差异
连接 RedGate VPN 后，先确认客户端显示已连接，再用同一浏览器、同一检测页面重新测试。必要时按浏览器说明清理 DNS 缓存，或退出浏览器后重开，减少旧记录干扰。重点观察原本属于本地网络的解析服务是否仍持续出现，而不是只看检测页有没有绿色提示。
如果结果异常，先把客户端临时切换为覆盖全部访问的模式（如支持），复测后再恢复工作所需的分流规则。若此时异常消失，应检查检测网站、浏览器或相关应用是否被设为直连，可参考分流教程逐项核对。浏览器自行使用的加密 DNS 也可能让结果不同于客户端预期，这属于需要确认的独立路径，不宜直接判为本地 DNS 泄漏。
仍无法判断时，每次只调整一个设置并记录结果；不要同时更换网络、线路和浏览器，否则很难定位原因。遇到连接反复中断或切换网络后保护失效，可先按连接排查教程处理，再重复检测。
团队验收：覆盖重连、分流与日常变化
团队检查不应只做一次。至少覆盖首次连接、断开后重连、Wi-Fi 与移动网络切换，以及恢复日常分流后的场景。若使用 Shadowrocket 或 V2RayNG，可分别参考Shadowrocket 使用教程与V2RayNG 使用教程核对客户端设置，不能照搬另一款客户端的开关名称。
建议由成员提交系统版本、客户端版本、测试时间、网络类型和脱敏后的结果，不收集订阅链接、完整浏览记录或账号凭据。DNS 检测通过不等于完全匿名，它只反映测试当时的部分解析路径。客户端更新、团队规则调整或网络变化后，应重新检查，并保留可复现的操作记录。