ClashX Meta 有官方下载网站吗？

项目发布版 README 明确说明没有官方网站。应从 MetaCubeX/ClashX.Meta 的 GitHub Releases 获取，不要把同名下载站当成官方来源。

Meta TUN DNS 显示 8.8.8.8，是否代表 DNS 已直接发给 Google？

不一定。它可能只是辅助程序设置的 TUN DNS，实际请求还需经 dns-hijack 和内部 nameserver 判断。必须结合 DNS 配置和连接测试。

为什么不能把 TUN DNS 改成路由器地址？

mihomo 文档说明 macOS 无法自动劫持发往局域网地址的 DNS 请求。改成 192.168.x.x 等地址可能绕过内部 DNS，造成非预期解析路径。

TUN 与 System Proxy 同时打开是否更好？

不会增加加密层数，也不一定提高覆盖率。先按应用需求选择一种清晰路径，再通过 Connections 和泄露测试验证。

Clash for macOS 技术详解——ClashX Meta 入门、TUN/DNS 防泄露与全软件代理指南

一、先弄清楚“Clash for macOS”指什么

这个称呼可能指早期 ClashX、带增强模式的 ClashX Pro、基于 mihomo 的 ClashX Meta、已经停更的 CFW macOS 版，或其他同名续建项目。它们的内核、菜单和配置字段并不完全一致。

截至资料核验时，MetaCubeX 的 ClashX Meta 最新发布版为 v1.4.46，发布于 2026 年 10 月 1 日。项目发布版 README 明确说明没有官方网站，因此应从 MetaCubeX/ClashX.Meta 的 GitHub Releases 下载，不要相信搜索引擎中的同名“官网”。

默认 master 分支可能保留旧代码，发布版使用 meta 分支和版本标签。普通用户应下载 Release，而不是按默认分支判断功能或自行编译旧代码。本文以 ClashX Meta v1.4.46 为主，旧 ClashX 与 CFW macOS 版只作必要区分。

二、系统代理、TUN、规则和 DNS 是四件事

系统代理只覆盖遵循 macOS 代理设置的程序，部分终端、UDP、游戏、Docker、虚拟机和后台服务可能忽略。
TUN 能接管更多程序，但结果仍取决于 auto-route、规则、UDP、IPv6、DNS 和其他 VPN/虚拟网卡。
Global 只处理已进入内核的流量，无法捕获绕过 Clash 的应用。
DoH 是加密而不是匿名；TUN 是接管方式也不是匿名。节点提供商仍可能看到原始公网 IP。
账号、Cookie、语言、时区、浏览器指纹、macOS 定位服务和 Wi-Fi 定位仍能提供位置或身份线索。

应用程序
   │
   │  ① 系统代理：应用主动连接本机 Clash 代理端口
   │  ② TUN：通过 utun 虚拟接口接管网络层流量
   ▼
ClashX Meta / mihomo
   │
   │  ③ 规则判断 / 全局连接 / 直接连接：决定出口
   │  ④ DNS：决定域名如何解析、通过哪条路径解析
   ▼
DIRECT 直连 / 代理节点 / REJECT 拒绝
   │
   ▼
目标网站或服务

三、安装与新手快速入门

只从 MetaCubeX/ClashX.Meta Releases 下载发布版 ZIP，解压后移动到“应用程序”。不要全局关闭 Gatekeeper 或对未知应用随意清除隔离属性。
首次启动按提示安装辅助程序并输入管理员密码，用于修改系统代理、TUN 和 DNS；只在确认来源后授权。
默认配置目录为 ~/.config/clash.meta/，可通过“配置 → 打开配置文件夹”进入，修改前先备份。
在“配置 → 托管配置 → 管理”中添加可信 HTTPS 配置 URL，或把本地 YAML 放入配置目录并选择它。
选择“规则判断”和实际节点，勾选“设置为系统代理”，用浏览器验证后，再决定是否需要 TUN。
“开机启动”只负责登录后启动应用，不代表节点、配置和 DNS 正常。

设置为系统代理：写入 macOS 的 HTTP/HTTPS/SOCKS 代理。Wi-Fi、以太网和其他网络服务可能需要分别检查，其他 VPN 也可能覆盖它。
Tun 模式：接管不读系统代理的流量。菜单勾选不等于真实运行正常，要同时检查 DNS、Connections 和实际出口。
出站模式：规则判断适合日常分流，全局连接适合测试，直接连接则不经过节点。
允许局域网连接：允许其他设备使用 Mac 的代理端口。默认关闭，本机 127.0.0.1 不需要它，公共 Wi-Fi 更不要随意开放。
复制终端代理命令：复制 HTTP/HTTPS/SOCKS 环境变量，仅对支持它们的终端和子进程有效；外部 IP 版本还涉及局域网开放。
托管配置与自动更新：用于远程节点和规则，更新可能覆盖手动修改，长期自定义应保留本地副本。
系统代理绕过列表：localhost、127.0.0.1、私网段和 *.local 通常应保留；需要代理的公网域名不要加入。
iCloud 配置同步：可能同步订阅地址、节点凭据和规则，启用前确认自己接受这些数据进入其他设备。
SSID 自动暂停：切换到指定 Wi-Fi 时可能恢复直连，是便利功能而不是隐私功能，应审查列表。
控制台与 Connections：查看进程、目标、TCP/UDP、命中规则和策略链，切换节点后关闭旧连接再测。
Sniffer：从 HTTP、TLS、QUIC 握手识别域名以辅助分流，不是完整 TLS 解密，也不提供匿名。
Fake IP 与缓存：用于域名映射，修改 DNS 或 TUN 后可清理异常缓存；它不是加密协议。
GEO 与 Providers：GEO 用于 GeoIP/GeoSite，Proxy/Rule Providers 提供远程节点和规则，更新来源必须可信。
远程控制器与 API：默认仅本机并设置 Secret，不把无认证 API 暴露到局域网或公网，也不交给不可信在线 Dashboard。
Alpha 内核：用于测试，普通用户不应在提升权限下盲目运行未经验证的内核。

五、System Proxy 与 TUN 如何选择

普通网页浏览：系统代理 + 规则判断 + 审查 DIRECT 和绕过列表即可，不必强行开启 TUN。
多个桌面软件、终端或 UDP：使用 TUN，并额外验证 DNS、IPv6 和 UDP。
同时打开 System Proxy 和 TUN 不会形成双重加密，反而可能增加排查难度。
排查统一出口时可暂时使用全局连接，并确认 GLOBAL 选择真实节点；测试后恢复合适的规则模式。
切换节点或配置后关闭旧连接，避免界面已改变而旧 TCP 连接仍走原出口。
可用 scutil --proxy 查看系统代理，用 networksetup -listallnetworkservices 查看网络服务名称。

六、ClashX Meta 的 TUN DNS 为什么特别容易误解

当前发布版源码中的默认 Meta TUN DNS 是 8.8.8.8。辅助程序在启用 TUN 时设置系统 DNS，mihomo 再通过 dns-hijack 将匹配的请求导入内部 DNS 模块。因此，Meta TUN DNS 不一定等于最终上游解析器。

mihomo 官方文档明确说明：macOS 和 Windows 无法自动劫持发往局域网地址的 DNS 请求。不要把 Meta TUN DNS 随意改成 192.168.1.1 等路由器地址，否则可能绕过内部 DNS。

确保 dns-hijack 同时覆盖 UDP 53 和 TCP 53。
scutil --dns 显示 8.8.8.8 时，不能只据此判断已经泄露或已经安全，还要检查内部 nameserver 和实际 DNS 连接。
TUN 关闭或异常退出后，检查系统 DNS 是否恢复；必要时在“网络 → 详细信息 → DNS”中恢复原设置。
部分版本升级后可能出现菜单状态与实际 TUN/DNS 状态不一致，必要时关闭再开启并执行真实测试。

七、当前 mihomo 的 DNS/TUN 配置示例

以下片段只用于说明当前 mihomo 字段，应合并到现有配置副本，不要直接覆盖完整订阅，也不要套用到旧 ClashX 或 CFW。

respect-rules 表示 DNS 连接遵守路由规则，但如果 DNS 服务器地址本身命中 DIRECT，查询仍会直连。
proxy-server-nameserver 用于解析代理节点自身域名，避免启动时的循环依赖；启动解析仍可能需要直接可用的 bootstrap DNS。
nameserver 可用 #策略组名称指定出口，例如 https://1.1.1.1/dns-query#Proxy，但 Proxy 必须替换为真实组名。
dns.ipv6: false 只抑制 AAAA 答案，不会关闭 macOS 的 IPv6。
auto-redirect 主要用于 Linux；strict-route 在官方文档中主要描述 Windows/Linux 行为，不是 macOS 的万能防泄露开关。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
  respect-rules: true
  proxy-server-nameserver:
    - "https://1.1.1.1/dns-query"
  nameserver:
    - "https://1.1.1.1/dns-query"
    - "https://8.8.8.8/dns-query"

tun:
  enable: true
  stack: gvisor
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - "any:53"
    - "tcp://any:53"

八、浏览器 DoH、IPv6、WebRTC、QUIC 与 Private Relay

浏览器安全 DNS 可能绕过内部 DNS 和 Fake IP。只有确认 TUN 与 DNS Hijack 正常后，才考虑暂时关闭浏览器 DoH 并复测。
IPv6 开关不是 macOS 总开关。若物理网络有公网 IPv6，而 TUN 只处理 IPv4，IPv6 网站仍可能显示原始地址。
WebRTC 可能通过 STUN 暴露额外地址。严格场景可评估 Chromium 的 disable_non_proxied_udp，但可能影响实时通话。
QUIC 使用 UDP，节点与 TUN 都必须明确其路径，不要假定失败时必然安全回退到 TCP。
iCloud Private Relay 会改变 Safari 及部分未加密流量的出口。与 Clash 同时启用时，Safari 可能显示与其他应用不同的 IP，应一次只测试一种明确路径。
macOS 定位服务可以利用附近 Wi-Fi 确定位置，应在“系统设置 → 隐私与安全性 → 定位服务”中按应用管理，而不是只看节点 IP。
TUN 开关不等于 Kill Switch。macOS 自带防火墙主要管理入站连接，不能单独作为完整的出站故障断网方案。

九、终端、Git、curl 与 SSH 的设置

终端不一定读取 macOS 系统代理。可以在当前 shell 临时设置环境变量，确认稳定后再决定是否写入 ~/.zshrc。端口以 ClashX Meta 实际显示为准。

Git 的 HTTP(S) 代理不会自动覆盖 SSH，SSH 需要 TUN 或 ProxyCommand。
Homebrew 和下载工具通常可读取环境变量，但应在同一终端会话设置并验证。
socks5h 与 socks5 的重要区别是主机名可交给代理解析。

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export all_proxy=socks5://127.0.0.1:7890

# curl 使用 HTTP 代理
curl --proxy http://127.0.0.1:7890 https://example.com/

# 使用 SOCKS 并让代理解析域名
curl --proxy socks5h://127.0.0.1:7890 https://example.com/

# Git 仅对 HTTP(S) 设置与撤销
git config --global http.proxy http://127.0.0.1:7890
git config --global --unset http.proxy

# 清除当前 shell 的代理变量
unset http_proxy https_proxy all_proxy
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY

# SSH 的 ProxyCommand 示例（仅针对指定 Host）
Host example.com
    ProxyCommand nc -X 5 -x 127.0.0.1:7890 %h %p

十、浏览器、IDE、Docker、虚拟机与游戏

Safari 通常遵循系统代理，但要同时检查 Private Relay、DIRECT、定位权限和 Connections。
Chrome/Edge 要排查代理扩展、安全 DNS、WebRTC 和 QUIC；Firefox 手动 SOCKS v5 时可启用远程 DNS。
IDE 主程序、插件、语言服务器、包管理器和内置终端可能分别维护网络设置，一个成功不代表全部成功。
Docker 容器内的 127.0.0.1 通常指向容器自己。host.docker.internal 能访问宿主机，但往往还涉及 Allow LAN、绑定和防火墙，不要在公共网络开放无认证代理。
Parallels、VMware 和模拟器可能使用 NAT、桥接或独立虚拟网卡，宿主机 TUN 不一定按预期接管，需在虚拟环境内分别验证 DNS 和路由。
游戏和实时语音通常需要 TUN 加 UDP 支持，启动器与主程序可能不同进程。ping/traceroute 不能可靠证明代理覆盖，因为 ICMP 与代理 TCP/UDP 不同。

十一、如何验证有效性与常见旁路

用 scutil --proxy 确认 HTTP/HTTPS/SOCKS 指向实际 Clash 端口，用 scutil --dns 检查系统解析器。
在 Connections 和日志中确认目标进程、规则、策略链和 UDP 记录；以 DIRECT 结尾表示未走节点。
分别测试 IPv4 和 IPv6，并用两个独立服务交叉验证。IP 地理数据库的城市不准确不等于泄露。
DNS 测试重点看运营商、路由器、非预期本地解析器和浏览器独立 DoH，公共 DNS 的 IP 不必等于节点 IP。
WebRTC 重点检查原始公网 IPv4/IPv6，.local mDNS 不应直接等同于公网泄露。
在睡眠唤醒、Wi-Fi 切换、节点切换、配置更新、ClashX Meta 重启和 TUN 异常关闭后重新测试。
Clash 停止后仍能直连公网，说明当前配置不是故障关闭的。

十二、常见问题与最终建议

Safari 有效但终端无效：终端未读取系统代理，使用环境变量、应用内代理或 TUN。
显示系统代理开启但仍是原始 IP：检查 DIRECT、绕过列表、IPv6、其他 VPN、Private Relay 和旧连接。
TUN 后无法联网：检查辅助程序、系统 DNS、dns-hijack、内部 DNS、其他 VPN 和协议栈，先恢复已知可用配置。
TUN 显示开启但终端仍直连：不要只看勾选，检查真实状态，必要时关闭再开启并查看日志和 scutil --dns。
Fake IP 导致个别服务异常：补充有针对性的 fake-ip-filter，不要盲目关闭整个 DNS 模块。
关闭 TUN 后 DNS 异常：检查系统 DNS 是否恢复，并按 Apple 的网络设置恢复原配置。
订阅更新后修改消失：使用本地副本管理长期自定义，不要直接编辑会被覆盖的远程文件。
高隐私需求：使用维护中的客户端，验证 DNS、WebRTC、Private Relay、定位与账号信息；需要故障断网时采用经过验证的出站控制方案。