GitHub Copilot DNS节点排行榜：网络延迟优化配置

先给个结论：GitHub Copilot在VS Code或Visual Studio里反应迟钝、补全卡顿、频繁超时，这事儿根子往往出在DNS上——你本地DNS解析出来的那个GitHub API节点，要么延迟高得离谱，要么干脆连不上。结果就是设备码认证卡住了，Copilot补全自然也跟着罢工。

确认Copilot当前解析的IP地址

先得搞清楚你电脑上的DNS到底把Copilot指向了哪。打开终端，跑两个命令就行：

nslookup api.github.com
nslookup copilot-proxy.githubusercontent.com

如果返回的IP属于140.82.112.0/20、185.199.108.0/22这些公开段，但用ping -c 4 [IP]一测，响应时间超过300ms——那就说明DNS没给你分配到最优节点。这种情况，就得手动给它换一条路。

手动绑定最优IP到hosts文件

方法一：直接用GitHub520项目验证过的低延迟IP组合（2026年5月实测有效）

先把hosts文件打开，注意权限：

• Windows：用记事本以管理员身份运行 → 文件→打开 → 路径填 C:WindowsSystem32driversetchosts
• macOS/Linux：终端执行 sudo nano /etc/hosts

在文件末尾追加下面两行就好，别把原有内容删了：

140.82.113.6 api.github.com
140.82.113.6 copilot-proxy.githubusercontent.com

保存后，终端里刷一下DNS缓存：Windows输入 ipconfig /flushdns，macOS执行 sudo killall -HUP mDNSResponder，Linux执行 sudo systemd-resolve --flush-caches。搞定。

使用FastGithub动态选择最优节点

如果觉得手动绑IP还是不够灵活，或者想自动切换最优节点，还有个方案——用FastGithub。

第一步：确保已安装.NET 6.0+，然后克隆并启动服务

git clone https://gitcode.com/gh_mirrors/fa/FastGithub → cd FastGithub → dotnet restore → dotnet build --configuration Release → dotnet run --configuration Release

第二步：把系统DNS指向本地服务

Windows的话，在网络适配器的IPv4属性里，把首选DNS设为 127.0.0.1；Linux或macOS，向 /etc/resolv.conf 文件首行添加 nameserver 127.0.0.1。

第三步：验证Copilot域名是否由FastGithub接管

再跑一次 nslookup api.github.com，如果返回的IP和之前不一样，并且连续三次ping的延迟都低于80ms——那就说明动态路由已经生效了，Copilot的响应速度应该会恢复正常。