---
name: claude-environment-check
description: 排查 macOS 与 Chromium 浏览器中的时区、语言、WebRTC 和 DNS/代理配置，基于实测逐项优化并提供回滚。用于 Claude 环境检测与网络隐私排障；不承诺固定分数或账号安全。
---

# Claude 环境自检与优化

把环境优化拆成四步：时区、浏览器语言、WebRTC/代理、DNS。先取基线，每次只改一类设置，复测后再进入下一步。用用户当前语言解释结果。

## 开始前

确认操作系统、浏览器及版本、代理客户端及内核版本、当前网络服务名称、使用场景（浏览器 / Claude Code / 两者），以及用户要“检查”还是已经授权“修改”。macOS 命令和 Mihomo YAML 只适用于相应环境；Surge 等客户端使用自己的配置语法。

记录当前时区、语言顺序、系统代理、TUN 状态、有效 DNS 配置与浏览器检测结果。只读检查可从下面开始；命令涉及管理员权限时由用户在本机交互式输入密码。

```bash
sudo systemsetup -gettimezone
networksetup -listallnetworkservices
scutil --proxy
scutil --dns
```

查看已确认的网络服务（下面的 Wi-Fi 只是示例，替换为实际名称）：

```bash
networksetup -getdnsservers "Wi-Fi"
```

记录代理环境变量是否存在即可；展示前隐藏认证信息、订阅链接和令牌。不要把完整代理配置、浏览器档案或原始网络日志上传到第三方。准备当前设置的本地备份、上一份可用配置和恢复方式；远程操作先确认断网后的恢复入口。

### 评分边界

- 本站 https://fuckclaude.xzggai.com/ 的结果是浏览器可见信号的参考评分，不是 Anthropic 的账号判定。不同工具、版本和设备权重不同。
- 发布本 Skill 时，本站时区权重 24、语言 18、中文字体 14、WebRTC 10；不能套用“时区立减 30”“语言立减 17”或固定“28 分安全”的结果。字体、区域格式、时差等仍可能有分数。
- 时区标识、出口 IP、实际所在地和账号支持地区是不同概念。切换时区不改变所在地或账号资格，也不证明所谓隐写规则被消除。

## 第一步：时区

先记录原时区与自动时区开关。用户确实需要采用相同 UTC 偏移的其他时区时，可以选择 Asia/Singapore；目前它与 Asia/Shanghai 都是 UTC+8，通常不改变显示的钟点，但会改变时区标识，日历和应用可能另有时区设置。

```bash
sudo systemsetup -settimezone Asia/Singapore
sudo systemsetup -gettimezone
```

自动时区可能覆盖手动设置：在“系统设置 → 通用 → 日期与时间”核对该开关。修改后重新打开受影响的浏览器/终端；在浏览器控制台或通过浏览器工具读取：

```javascript
Intl.DateTimeFormat().resolvedOptions().timeZone
new Date().getTimezoneOffset()
```

完成标准：系统读回与浏览器读回一致，日期和本地钟点符合预期。出现 Error:-99 或其他错误时，不直接判为无害；读取实际设置和时间，以读回为准，未确认则报告失败或未验证。

回滚：用 `sudo systemsetup -settimezone "原先记录的时区"` 恢复，并还原自动时区开关。

## 第二步：浏览器语言

在 `chrome://settings/languages` 查看实际顺序。用户希望使用英文环境时，将 English (United States) 置顶；仅在用户希望移除中文偏好时删除中文条目。操作可能改变网页默认语言、翻译行为和日期格式。

重启或新建浏览器窗口后读回：

```javascript
navigator.language
navigator.languages
Intl.DateTimeFormat().resolvedOptions().locale
```

完成标准：读回值符合用户选择。删除一个中文条目不保证列表仅有 `en-US`；检查其他中文变体、浏览器自动补充项、配置文件与管理策略，不宣称某个固定减分。不要为清分删除系统字体。

回滚：按备份还原语言条目及顺序。

## 第三步：WebRTC 与代理路径

先区分系统 HTTP/SOCKS 代理、应用自己的代理设置和 TUN 路由；浏览器与终端分别测试。系统代理不一定覆盖 WebRTC UDP，具体取决于浏览器策略、代理能力、路由和网络。

可选择一种适合现有环境的方法并验证：

1. Chromium 的扩展 API 支持 `webRTCIPHandlingPolicy = disable_non_proxied_udp`。若使用 WebRTC Control 等扩展，核对来源、权限及实际策略控制权；安装动作在授权范围内完成。启用后测试视频会议、语音和屏幕共享是否仍符合用户需要。
2. 对已有 Mihomo 客户端，确认 TUN 的路由、UDP、IPv6、排除规则和 DNS 劫持生效，再考虑切换为仅 TUN。先保持可恢复的连接，再关闭系统代理；每一步验证浏览器和终端出口。系统代理开关不会自动清除 shell 中已有的 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY、NO_PROXY 或应用自有设置。

不要承诺“纯 TUN 完全不可检测”。核对 `scutil --proxy` 和 shell 变量的存在情况；确需清除时只改确认属于该客户端的设置，并记录恢复方法，保留用户所需的企业/VPN/应用代理。

在相同网络、浏览器和检测方法下，对比 WebRTC ICE 结果及预期出口。私网地址、mDNS 候选、公网地址要分别解释。“无 WebRTC 数据”只表示本次没有拿到候选，可能是权限、超时或策略阻止，不能单独证明零泄露。

完成标准：在测试范围内未观察到非预期出口，正常网络及必要的实时通信功能可用。失败则恢复上一项改动，避免连续叠加配置。

## 第四步：DNS 路径

检查系统解析器、客户端生效配置和 Chrome 安全 DNS 三层，而非只看订阅文件。区分：普通域名解析、DIRECT 域名解析、代理节点域名解析、DoH 服务器域名引导解析。公共 DNS 位于海外或使用 HTTPS，并不意味着请求一定经代理发送。

### Mihomo 合并配置参考

先读取当前配置；保留已用代理组、分流规则和必要的局域网/企业 DNS。下面是待适配的增量示例，不是可覆盖任意订阅的整份配置。`YOUR_EXISTING_PROXY_GROUP` 必须替换为已存在且可用的代理或代理组，不能原样应用。

```yaml
tun:
  enable: true
  auto-route: true
  auto-detect-interface: true
  strict-route: true
  dns-hijack:
    - any:53
    - tcp://any:53

dns:
  enable: true
  enhanced-mode: fake-ip
  default-nameserver:
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - https://1.1.1.1/dns-query
  nameserver:
    - "https://1.1.1.1/dns-query#YOUR_EXISTING_PROXY_GROUP"
    - "https://8.8.8.8/dns-query#YOUR_EXISTING_PROXY_GROUP"
```

此示例将普通 DNS 上游显式关联至已有代理组，但代理节点的引导解析仍须单独验证，不能依赖尚未解析成功的同一代理。若这些 DoH 在现有网络不可达，先解决引导链路或恢复原配置，不直接重启切断连接。

根据实际策略决定是否保留 `direct-nameserver`（如国内 DNS）：保留意味着允许该类直连域名走这些解析器，不能再宣称“绝不访问国内 DNS”。`nameserver-policy`、fallback、排除规则或其他合并项可能覆盖示例；以最终有效配置为准。配置中只保留一份同名顶层键，明确客户端的数组合并/替换行为。

`strict-route` 的效果因平台而异；Mihomo 文档明确 macOS/Windows 无法自动劫持发往局域网的 DNS 请求。保留已有可用 stack 和监听端口，不盲目使用 `listen: :53` 或把服务器暴露给局域网。可用内核的配置检查命令（如 `mihomo -t -f 文件路径`）验证最终配置后，再按客户端提供的方式应用。

### 验证与系统设置

```bash
nslookup claude.ai
scutil --dns
```

返回 `198.18.x.x` 只能证明这次查询拿到了 Fake-IP 映射，不证明后续真实解析一定发生在远端。结合客户端 DNS/连接日志、物理网卡上的 DNS 流量观测、IPv4/IPv6 路由及可信的 DNS leak 测试交叉验证。53/853 端口没有明文请求也无法排除经 HTTPS 发送的 DNS。记录测试方法与时间，不把无法观测的部分写成已通过。

只在确认会改善该网络且有回滚记录时修改系统 DNS。示例：

```bash
sudo networksetup -setdnsservers "Wi-Fi" 1.1.1.1 8.8.8.8
```

若原先是 DHCP 自动分配，回滚为 `sudo networksetup -setdnsservers "Wi-Fi" empty`；原先是静态列表则恢复原列表。注意企业内部域名、门户登录与局域网服务。

Chrome 显示“由组织管理”或安全 DNS 锁定时，查看 `chrome://policy` 与 `chrome://management` 的策略来源。企业设备由管理员修改；个人设备区分用户偏好、扩展与配置描述文件。普通 `defaults write` 不等同于管理策略生效，也不是绕过受管策略的可靠办法。经授权使用受支持的设置方式，重启后在 `chrome://policy` 和实际解析路径中确认。

## 验收与交付

回到 https://fuckclaude.xzggai.com/ 使用相同浏览器重测，列出“项 / 修改前 / 修改后 / 证据 / 回滚方式”。区分已验证、失败、未验证三种状态，并说明对语言显示、日历、视频会议和局域网访问的影响。

完成以实际设置和网络连通性验证为准，不以某个分数为准。写“本次测试未观察到某类泄露”，不要写“永久零泄露”或“保证不封号”。如果没有工具或权限，明确等待用户完成的检查，不编造检测结果。

## 官方参考

网络配置前核对当前客户端版本与对应文档；以下链接核对日期为 2026-10-15。

- [Apple 日期与时间设置](https://support.apple.com/guide/mac-help/mchlp1124/mac)
- [Apple systemsetup](https://support.apple.com/en-bw/guide/remote-desktop/apd95406b8d/mac)
- [Chrome WebRTC 隐私策略 API](https://developer.chrome.com/docs/extensions/reference/api/privacy)
- [Mihomo TUN](https://wiki.metacubex.one/config/inbound/tun/)
- [Mihomo DNS 与上游路由](https://wiki.metacubex.one/config/dns/)
- [Chrome 企业策略](https://chromeenterprise.google/policies/)
- [Chromium 管理策略与偏好](https://www.chromium.org/developers/design-documents/preferences/)