在企业内网开发环境中，开发者常会遇到终端（如 Git、curl）无法解析内网域名，但浏览器却能正常访问的情况。本文基于 macOS 系统的网络解析机制，提供一套标准化的排查与解决流程。

一、 故障现象与底层机制分析

故障现象

在终端执行 git push 或 curl 请求内网服务时，报错 Could not resolve host: <internal-domain>。但使用 nslookup <internal-domain> 却能成功获取对应的内网 IP 地址。

底层机制差异

该问题的核心在于 nslookup 与系统级网络请求工具（如 Git 底层的 libcurl）采用了不同的解析机制：

  • nslookup：使用内置的 DNS 客户端，直接向 /etc/resolv.conf 或 VPN 分配的 DNS 服务器发起查询，仅验证 DNS 记录是否存在。
  • 系统级工具（libcurl/Git）：调用 macOS 底层的系统解析器（libresolv）。该解析器不仅依赖 DNS 服务器，还会严格校验系统路由表（Routing Table）。若 VPN 未将目标 IP 所在网段正确注入路由表，系统解析器会判定目标不可达，从而直接拒绝解析并返回错误。

二、 前置排查：清理残留代理配置

在深入排查前，需排除代理软件关闭后残留的配置干扰。

  1. 清除 Git 全局代理：
git config --global --unset http.proxy
git config --global --unset https.proxy
  1. 清除当前终端环境变量：
unset http_proxy https_proxy HTTP_PROXY HTTPS_PROXY ALL_PROXY

若清理后问题依旧，建议采用以下方案绕过系统底层 DNS 解析。

三、 解决方案：基于 SSH 协议的强制 IP 解析

通过配置 SSH 客户端，使其在连接特定域名时直接指定内网 IP，从而彻底绕过 macOS 的 DNS 解析器。

步骤 1：配置 SSH 强制解析

编辑或创建 SSH 配置文件：

nano ~/.ssh/config

添加以下配置（将 IP 和域名替换为实际环境中的值）：

Host <internal-domain>
    HostName <internal-ip>
    User git
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

步骤 2：验证 SSH 连通性

执行以下命令测试连接：

ssh -T git@<internal-domain>

若返回预期的欢迎信息，则表明 SSH 通道已成功打通。

步骤 3：切换远程仓库协议并推送

确保当前处于 Git 仓库根目录，执行以下命令将远程地址切换为 SSH 协议：

git remote set-url origin git@<internal-domain>:<group>/<project>.git

随后正常执行推送操作：

git push -uf origin main

四、 临时替代方案：HTTPS 强制解析

若当前环境未配置 SSH 密钥，仅需临时完成一次 HTTPS 协议的推送，可利用 Git 的底层参数强制指定解析 IP：

git -c http.curloptResolve="<internal-domain>:443:<internal-ip>" push -uf origin main

五、 注意事项

  1. 工作目录校验：执行 git remote 等命令前，务必确认当前处于包含 .git 目录的项目根目录，避免触发 fatal: not a git repository 错误。
  2. 文件权限控制：macOS 对 SSH 配置文件权限要求严格。若连接失败，请执行 chmod 700 ~/.ssh 及 chmod 600 ~/.ssh/config 修复权限。
  3. 长期修复建议：本文提供的方案为客户端侧的规避措施。若团队内普遍存在此问题，建议联系网络管理员检查 VPN 配置文件，确保 dhcp-option DNS 及对应网段的路由规则已正确下发。