direct-link

KO | EN

gitlite — search

#javascript #machine-learning #rust #deep-learning #linux #docker #macos #nodejs #windows #awesome-list #pytorch #mcp #openai #open-source

(★ 61)

免费好用的加速器

direct-link Latest Version Download

Download Latest Version (.zip)

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

# Steam 商店加载不出图片、GitHub clone 一直卡住，聊聊我是怎么解决的

最近用 Steam 和 GitHub 的时候经常遇到一些问题。Steam 商店能打开但图片全是裂的，社区页面转圈半天进不去。GitHub 上 `git clone` 一个项目，速度停留在个位数 KB 每秒，有时候直接卡死重试。

我花了点时间研究了一下原因，然后自己动手做了个小工具来处理。这篇文章主要记录排查过程和解决思路，希望对遇到同样问题的人有参考价值。

## 为什么会慢

我所在的网络环境下，Steam 和 GitHub 访问慢，大部分时候不是带宽的问题，而是 DNS 解析环节出了偏差。

电脑访问一个网站前，先要问 DNS 服务器："这个域名的 IP 是多少？" 运营商的 DNS 返回的 IP 有时候不是最优的，甚至是完全不可达的。你连到一个错误的 IP，当然慢，或者根本连不上。

我实际测试过，对 `store.steampowered.com` 这个域名，系统 DNS 返回的 IP 和通过 DNS-over-HTTPS 查到的 IP 是不一样的。前者延迟高、丢包重，后者延迟低、连接稳定。

所以核心思路是：绕过可能不可靠的 DNS 解析，用更可靠的方式拿到目标域名的可用 IP，然后让电脑直连这个 IP。

## 我做了什么

我写了一个叫 DirectLink 的小工具，用 Go 语言写的，做的事情可以拆成几步。

**第一步，查 IP。** 工具会通过 DNS-over-HTTPS 向阿里 DNS 和 DNSPod 查询目标域名的 A 记录。这两个服务在国内可以直接访问，返回的 IP 通常是干净的。每个服务查两轮，因为 CDN 的负载均衡机制每次可能返回不同的边缘节点 IP，多查几次能拿到更多候选。

**第二步，测速和验证。** 拿到候选 IP 后，对每个 IP 做 TCP 连接测速（443 端口），然后做 TLS 握手验证——确认证书确实属于这个域名，而不是被劫持到了其他地方。对 GitHub 的主域名，还会额外测试 22 端口，因为 `git clone` 走 SSH 协议用的就是这个端口。有些 IP 虽然能通 443，但 22 端口不开放，SSH 方式 clone 就会失败。

**第三步，写入 hosts 或走代理。** 验证通过的 IP 写入系统 hosts 文件，浏览器下次访问时就会直连这个 IP。对于某些 TCP 层面完全不通的域名（比如我的网络下 steamcommunity.com 的所有候选 IP 都连不上 443 端口），工具会启动一个本地代理，通过一台中转服务器来转发流量。

**第四步，持续维护。** 工具在后台运行，每隔一段时间重新探测，更新最优 IP。如果某个 IP 突然不通了，会自动切换到备用 IP。这样即使 CDN 节点 IP 变化或者被封锁，也不需要手动干预。

## 关于中转

老实说，不是所有域名都能靠换 IP 解决。我测试下来，GitHub 的大部分域名（api、raw、codeload 等）通过 DoH 查到的 IP 可以直连，延迟在 70-280ms 之间。但 steamcommunity.com 在我的网络环境下，无论用哪个 IP 都连不上 443 端口——这已经不是 DNS 污染了，是 TCP 层面的封锁。

这种情况下只有一个办法：通过一台中间服务器转发流量。我在阿里云上开了一台轻量服务器，上面跑一个 SOCKS5 代理。工具检测到某个域名直连不通时，就把这个域名的流量交给 SOCKS5 代理，由服务器去连接目标网站。服务器在国内，到 GitHub 和 Steam 的连通性比我的家宽好一些。

中转的代价是多了一跳，延迟会增加 200-300ms，但好处是稳定——不再受本地网络封锁的影响。而且只对直连不通的域名走中转，能直连的域名还是走 hosts 直连，不会无谓地增加延迟。

## 实际效果

记录一下我网络环境下的探测数据，供参考。

GitHub 方面，`github.com` 直连最优 IP 的延迟约 70-280ms（取决于走哪个 IP 段），22 端口同步可用。`raw.githubusercontent.com` 延迟约 70-100ms。`codeload.github.com`（git clone 用的域名）延迟约 270ms。这几个域名加 hosts 直连后，clone 速度从之前的 20KB/s 提升到正常带宽水平。

Steam 方面，商店和 CDN 图片域名延迟约 40-50ms，加 hosts 后图片正常加载。但 `steamcommunity.com` 在我的网络下必须走中转，直连方案无法绕过 TCP 封锁。

## 一些技术细节

DNS-over-HTTPS 我用的是阿里 DNS（223.5.5.5）和 DNSPub（doh.pub）两个源。Cloudflare 和 Google 的 DoH 服务在我的网络下连不上，所以没有采用。查询时直接用 IP 地址访问 DoH 接口，避免了对 DoH 服务器本身的 DNS 解析依赖。

hosts 文件写入用的是标记块隔离的方式——只在 hosts 文件中添加一个标记块，不修改用户原有的任何内容。退出时自动清理这个标记块。文件替换用的是原子操作（重命名），避免写入过程中断导致 hosts 文件损坏。

TLS 验证这一步比较关键。有些 DNS 返回的 IP 虽然 TCP 能通，但 TLS 握手时证书不匹配，说明这个 IP 并不真正服务该域名。如果直接用这种 IP，浏览器会报证书错误。所以我只保留 TLS 验证通过的 IP。

## 局限

也有搞不定的情况。steamcommunity.com 在部分地区的网络下被 TCP 层面封锁，纯 hosts 方案无法解决，只能依赖中转。中转服务器的稳定性和带宽也是影响因素——如果中转服务器本身到目标网站的网络不好，中转也没用。

另外，浏览器有自己的 DNS 缓存，hosts 文件修改后不一定会立即生效。Chrome 需要重启或者等待缓存过期，也可以在 `chrome://net-internals/#dns` 手动清除。这个问题比较容易踩坑。

目前这个工具只覆盖了 Steam 和 GitHub 两个站点。后续如果有需求，加新站点只需要在配置文件里加几行域名规则。

direct-link

direct-link Latest Version Download

Today's picks

Was this content helpful?

Recent Feedback

direct-link

direct-link Latest Version Download

Today's picks

Was this content helpful?

Recent Feedback

Download README