macOS 使用 ClashX Meta 开启 TUN 后，Git SSH 连接 GitHub 失败的排查与解决
最近在 macOS 上使用 ClashX Meta，并开启 TUN 模式后，发现所有通过 SSH 访问 GitHub 的 Git 操作都会失败，例如：
报错信息类似：
乍一看很像是 SSH key 权限问题，或者仓库不存在。
但实际并不是 GitHub 权限问题，而是 ClashX Meta 的 TUN / fake-ip 机制影响了 SSH 连接。
排查过程
先查看 github.com 的 DNS 解析结果：
输出中可以看到：
然后再执行：
输出中出现：
关键点是这个 IP：
198.18.x.x 并不是 GitHub 的真实公网 IP，而是 Clash / mihomo 在 fake-ip 模式下返回的虚拟 IP。
也就是说：
SSH 实际连接的是 fake-ip，而不是 GitHub 的真实地址。
根因分析
ClashX Meta 开启 TUN 模式后，通常会配合 fake-ip DNS 模式使用。
fake-ip 的作用是：当系统请求某个域名时，Clash 不直接返回真实 IP，而是返回一个虚拟 IP，例如：
随后 Clash 根据这个 fake-ip 找回原始域名，并按照规则进行代理或直连。
浏览器、HTTP、HTTPS 流量一般问题不大，但 SSH 这种非 HTTP 流量，尤其是 GitHub 默认的 22 端口 SSH，有时会被 TUN / fake-ip 处理异常，最终导致连接被关闭。
所以这个错误：
并不代表 GitHub 拒绝了你的 SSH key，而是 Clash 的 TUN / fake-ip 链路没有正确处理这条 SSH 连接。
最终解决方案：让 GitHub SSH 改走 443 端口
GitHub 官方支持通过 443 端口使用 SSH，主机名是：
也就是说，把原来的：
改成：
这样可以绕开 TUN 模式下 22 端口 SSH 被 fake-ip 影响的问题。
配置步骤
1. 编辑 SSH 配置文件
添加以下内容：
如果你的 SSH 私钥不是 id_ed25519，可以先查看：
如果你用的是 id_rsa，则改成：
2. 修改配置文件权限
3. 验证配置是否生效
执行：
正常应该看到类似输出：
重点确认这两项：
如果仍然是：
说明 ~/.ssh/config 没有正确生效，需要检查文件路径、权限或是否存在重复配置。
4. 测试 GitHub SSH
第一次连接可能会提示是否信任 host，输入：
如果成功，会看到类似：
这说明 SSH 认证已经成功。
5. 测试 Git 操作
回到项目目录，执行：
或者：
如果可以正常执行，说明问题已经解决。
会不会影响公司内网 GitLab？
不会。
前提是 SSH 配置必须只写给 github.com：
这只会影响 GitHub 的 SSH 连接。
例如下面这些地址不会受影响：
真正需要避免的是这种写法：
Host * 会影响所有 SSH 连接，包括公司内网 GitLab、跳板机、服务器登录等。
如果需要确认公司 GitLab 是否被影响，可以执行：
正常情况下应该还是：
只要没有变成：
就说明没有误伤。
也可以从 Clash 配置侧修复
另一种方式是在 Clash / mihomo 配置中给 GitHub 加入 fake-ip-filter：
或者把 DNS 模式从：
改成：
不过这种方式依赖 Clash 配置和订阅模板，不同配置之间差异较大。
相比之下，给 GitHub SSH 单独配置 443 端口更简单、更稳定，也不会影响其他 SSH 连接。
最终推荐配置
最终 ~/.ssh/config 中只需要加这一段：
然后执行：
确认成功后，正常使用：
即可。
总结
macOS 使用 ClashX Meta 开启 TUN 模式后，如果 GitHub SSH 出现：
一般不是 SSH key 或 GitHub 权限问题，而是 fake-ip + TUN 对 SSH 22 端口处理异常。
最简单稳定的解决方案是：
这样 GitHub SSH 会改走 ssh.github.com:443，普通 Git 命令不需要修改，且不会影响公司内网 GitLab。