GitHub Pages 又打不开了。这句话在中文开发者圈子里出现的频率，差不多和「GitHub Pages 真香」一样高——免费、稳定、绑定仓库自动部署，作为静态博客和项目主页的托管方案几乎没有对手，唯一的死穴是国内访问：时快时慢，隔三差五直接白屏，而且一坏就是好几天。
这篇用 2026 年 10 月下旬的一轮实测数据，把「GitHub Pages 国内打不开」这件事讲透：到底是什么坏了、怎么 5 分钟自查、为什么网上流传的换 DNS 大法救不了你，以及 5 种真正有效的解决方案——从零成本等待到整体迁移，按你的情况对号入座。
30 秒速答
- 先查官方状态：status.github.com，Pages 绿了再怀疑别的（10 月 19 日刚出过一次官方故障）。
- 全球能开、国内打不开 = 链路干扰，不是你的站挂了，也不是域名被墙。
- 换 DNS、补 A 记录基本没用：实测四个官方 IP 全部同等被干扰，DNS 层无解。
- 最快见效：套 Cloudflare 代理（不迁移）或整体迁到 Netlify / Vercel。
- 国内受众为主且已备案：腾讯 EdgeOne Pages 是大厂免费选项。
- Gitee Pages 别试了：2024 年已停服，旧教程全是坑。
先分清：三种「打不开」是三件事
排查第一步不是动手改配置，是搞清楚你属于哪种情况。三种可能，处理方式完全不同。
第一种：GitHub 官方故障。 GitHub Pages 自己挂了，全球都打不开。2026 年 10 月 19 日（北京时间 23:49 到次日 00:56）就发生过一次，Actions、Pages、Webhooks 一起降级约一小时。这种不用你做任何事，打开 status.github.com 确认后等官方修就行。
第二种：你本地网络的问题。 路由器抽风、DNS 缓存污染、公司网管的策略限制。判别方法简单：手机关 WiFi 用流量试一次，能开就是你本地宽带或路由的问题，跟 GitHub 没关系。
第三种：链路干扰（最常见的元凶）。 你的站全球都能访问，只有国内时通时不通。这是本文的主角，也是 2026 年 10 月这波「GitHub Pages 集体白屏」的真相。下面用实测数据说话。
5 分钟自查：定位到具体哪一层坏了
拿一个托管在 GitHub Pages 上的域名（比如你自己的博客），照着做两步。
第一步，外部视角。 打开 check-host.net 这类多节点检测工具，跑一次 HTTP 检测。如果海外节点全部 200、国内节点失败，就是链路干扰；如果全球都失败，回到上一节查官方状态。
第二步，分阶段计时。 电脑上跑一条命令（Windows 用 curl，系统自带或装一个）：
curl -o NUL -w "dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} code=%{http_code}\n" https://你的域名/
多跑几次，看输出的四个数字。这套数字能直接告诉你坏在哪一层：
| 现象 | 含义 |
|---|---|
| code=000 且 tcp=0.000000 | TCP 握手没完成，连接请求被丢弃——链路层干扰 |
| dns 很大或失败 | DNS 解析问题，换 223.5.5.5 试试 |
| tcp 正常但 tls 超过 5 秒 | TLS 握手被拖慢，浏览器端早已超时——同属链路干扰 |
| 全部正常但页面慢 | 带宽问题，和「打不开」是两回事 |
实测：2026 年 10 月这波干扰长什么样
下面这组数据来自 2026 年 10 月 21 日下午对一个 GitHub Pages 自定义域名站点的实测，可以当参照模板。
连续 16 次请求：8 次成功，8 次失败。 失败的 8 次全部是 tcp=0.000000——TCP 三次握手根本没完成，连接请求发出去就没了。而且失败不是随机的，是成簇出现：连续失败三四个，再恢复一两个，再来一串。这是链路层间歇性干扰的典型形态，不是服务器过载（过载会返回慢，不会直接丢 SYN）。
连上的请求里，近半数 TLS 握手超过 5 秒。 8 次成功的 TLS 握手耗时分别是 0.26 秒、0.86 秒、1.17 秒、1.37 秒、5.13 秒、5.43 秒、5.71 秒——后面几次虽然「成功」了，但浏览器等不了这么久，用户看到的还是白屏转圈。
四个官方 IP 全部中招。 GitHub Pages 官方要求域名配四条 A 记录（185.199.108.153 / 109.153 / 110.153 / 111.153）。逐个测试，三个节点的成功率分别是 4/8、3/8、4/8——没有哪个 IP 是干净的。
同一时刻的对照组全部正常。 这是最能说明问题的一组数据：
| 目标 | 成功率 | 平均 TLS 握手 |
|---|---|---|
| 百度（基线） | 5/5 | 0.14 秒 |
| Vercel | 4/5 | 0.17 秒 |
| Netlify | 5/5 | 0.35 秒 |
| Cloudflare | 5/5 | 0.47 秒 |
| 阿里云 OSS（广州） | 5/5 | 0.92 秒 |
| GitHub Pages 站点 | 8/16 | 0.26–5.71 秒 |
同一台电脑、同一个网络、同一时间段，只有走 185.199 段的请求挂掉。另外用 pages.github.com 的域名去访问同一个 IP，同样失败——说明被干扰的是整个 IP 段的链路，不是某个具体域名被针对。
为什么换 DNS 救不了你
网上流传最广的方子是「换 223.5.5.5」和「补齐四条 A 记录」。前者针对 DNS 污染（本地解析到错误 IP），后者针对单点故障（只配一条 A 记录没有冗余）。这两招在各自的场景里是对的，但在 IP 段级干扰面前都是无效操作：
- 换 DNS 解析出来的还是那四个 IP，IP 本身全在被干扰的段里；
- 补齐四条 A 记录，等于把同一条坏路复制四份——实测四个节点成功率都在五成上下，没有干净的 IP 可路由。
DNS 层能决定「你去哪个 IP」，决定不了「这个 IP 通不通」。分清这一层，能帮你省掉大量无效折腾。
5 种解决方案，按你的情况选
方案一：等待 + 监测（成本为零）
链路干扰历史上多是间歇性的，几天到几周内会缓解或变化。如果你的站访问量不大、不靠它吃饭，挂个监测（UptimeRobot 之类的免费服务，注意选有海外探测点的）等恢复是合理选择。适合：个人项目页、低流量博客。
方案二：DNS 分流双线部署（不动主站，效果最好）
思路：域名解析按线路分流——境外线路照旧指向 GitHub Pages，境内线路指向另一个托管平台的域名。国内用户访问走国内可达的节点，海外用户不受影响，GitHub 上的部署流程一行不改。
具体操作：在 DNSPod（腾讯云域名解析）这类支持分线路的 DNS 服务商处，把 www 记录配两条——「境外」线路 CNAME 到 你的用户名.github.io，「境内」线路 CNAME 到 Vercel 或 EdgeOne Pages 的接入域名（Vercel 是 cname.vercel-dns.com）。另一边的平台用 GitHub 仓库直接构建，或者干脆托管你 hexo d 推上去的静态分支。
这个方案的妙处是主备合一：就算其中一条线彻底挂了，改一条 DNS 记录就能全量切到另一边。适合：有一定动手能力的站长，想一劳永逸的。
方案三：Cloudflare 代理（改动最小，见效最快）
不迁移、不改部署，把域名的 NS 服务器改到 Cloudflare，DNS 记录里 A 记录照旧指向 GitHub Pages 的四个 IP，但开启代理（橙色云朵），SSL/TLS 模式设为 Full。用户访问的是 Cloudflare 的边缘节点，彻底绕开 185.199 段。
实测 Cloudflare 可达性 5/5，TLS 握手 0.47 秒——不算快，但对「一半请求打不开」的现状是降维打击。代价：免费版国内速度一般、偶尔也有波动，而且 NS 迁移期间解析会短暂生效延迟。适合：想最快止血、不想动部署流程的。
方案四：整体迁移（Netlify / Vercel / EdgeOne Pages）
托管平台本身换掉，GitHub 仓库继续当代码源，构建交给新平台。
- Netlify：实测 5/5 全通、TLS 0.35 秒。免费版每月 100GB 带宽（日 PV 三千左右的站月流量约 10GB，远够），支持 GitHub 仓库自动构建、自定义域名自动签 HTTPS。Hexo 迁移几乎零改动。
- Vercel：实测 4/5、TLS 0.17 秒，速度最好但连通率偶尔抽风。免费版同样 100GB/月。注意
*.vercel.app默认域名在国内受限，必须绑自定义域名。 - 腾讯 EdgeOne Pages：国内大厂，有长期免费版，支持 GitHub 仓库自动构建，Hexo/Hugo 有预设模板。关键限制：要用国内加速节点，域名必须完成 ICP 备案；未备案只能走它的海外节点，速度优势没了。适合已备案的站。
迁移时保住 SEO 的三个动作：新旧站并行跑几天再切 DNS；确认所有页面 URL 与原来完全一致；TTL 提前降到 600，选流量低谷切换。
方案五：多入口冗余
主站不动，用一个子域名（比如 fast.你的域名）挂一份镜像到国内可达的平台，主页放一行「国内访问慢？试试加速入口」。不优雅，但对「内容站」是最诚实的兜底——用户要的是看到内容，不是欣赏你的架构。
决策表
| 你的情况 | 推荐方案 |
|---|---|
| 个人项目页，流量无所谓 | 方案一：等待 + 挂监测 |
| 有动手能力，想一劳永逸 | 方案二：DNS 分流双线 |
| 要最快恢复，部署流程不想动 | 方案三：Cloudflare 代理 |
| 彻底受够了，愿意花半天迁移 | 方案四：Netlify / Vercel |
| 已备案、国内用户占绝对多数 | 方案四的 EdgeOne Pages（国内节点） |
| 内容站，先保证用户能看到东西 | 方案五：多入口冗余 |
顺带说一句站长的另一半刚需：部署再稳，git push 到 GitHub 本身也需要一条过得去的网络线路，clone 大仓库、拉依赖的时候尤其明显。网络环境的完整搭建路径在科学上网方案怎么选里有对比分析，想彻底摆脱「时通时断」的可以延伸过去。
FAQ
Q：GitHub Pages 是被墙了吗？
不是你的域名被单独墙。实测证据：用 pages.github.com 的域名访问同一个 IP 同样失败，说明被干扰的是整个 185.199.108-111.153 IP 段的链路，而不是某个具体网站。这种情况历史上多次出现，通常是间歇性的，几天到几周内会缓解或变化。
Q：换 DNS 有用吗？
作用有限。如果干扰是 IP 段级别的（实测四个官方 IP 成功率都在五成上下），换 DNS 解析出来的还是同样的 IP。换 DNS 只在两种情况有用：你的本地 DNS 被污染返回了错误 IP，或者你只配了一条 A 记录、需要补齐官方要求的四条做冗余——但别指望它解决链路干扰本身。
Q：套 Cloudflare 能解决吗？
能绕开 185.199 段，这是目前不迁移就生效的最快方案。把域名 NS 改到 Cloudflare，A 记录指向 GitHub Pages 并开启代理（橙色云朵），SSL 模式设为 Full。代价是 CF 免费版在国内的速度一般（实测 TLS 握手 0.47 秒），且偶尔也有波动，但对「打不开」这个量级的问题是降维打击。
Q：Gitee Pages 还能当国内镜像吗？
不能。Gitee Pages 已于 2024 年停止服务，现在网上大量旧教程还在推荐它，照着操作只会浪费时间。国内大厂的替代品是腾讯云 EdgeOne Pages（有长期免费版，支持 GitHub 仓库自动构建），但要用国内加速节点需要域名完成 ICP 备案，未备案只能走它的海外节点。
Q：会不会是 GitHub 官方故障？
有可能，先排除这个。打开 status.github.com 看 Pages 的状态，绿了再怀疑链路。2026 年 10 月 19 日（北京时间 23:49 到次日 00:56）GitHub Pages 就出过一次约一小时的官方故障。官方故障和链路干扰的表现不一样：前者是全球性打不开，后者是海外访问正常、只有国内不行——用检测工具跑一遍全球节点就能区分。
Q：迁移到 Netlify 或 Vercel 会影响 SEO 吗？
域名不变、迁移操作得当的话影响很小。关键三点：迁移前新旧站并行跑几天；确认迁移后所有页面的 URL 与原来完全一致；DNS 切换选在流量低谷，TTL 提前降到 600。搜索引擎认的是域名和 URL 结构，不是托管平台。
Q：EdgeOne Pages 是免费的吗？
有长期免费版，静态托管、自动构建、HTTPS 都包含，对个人博客够用。它支持直接关联 GitHub 仓库自动部署，Hexo、Hugo 都有预设模板。限制是：要用国内加速节点，域名必须完成 ICP 备案；未备案只能使用海外节点，速度优势就没了。
Q：我不是站长，只是想看别人挂在 GitHub Pages 上的网站怎么办？
这是你本地网络到海外线路的问题，不是网站的问题。能做的：换个网络环境试试（手机流量和宽带的表现经常不一样）、多刷新几次（间歇性干扰下有概率连上）、或者从根本上解决网络环境。网络环境怎么配，科学上网完全指南里有完整路径。
最后
GitHub Pages 的问题从来不是「它不好」，而是它的出口线路在你和它之间隔着一层不可控的东西。这轮实测最有价值的结论其实就一句：先搞清楚坏在哪一层，再决定动不动手——官方故障等一等就好，本地网络换条路，链路干扰才值得你上 Cloudflare 或者搬家。
至于最后一点自知之明：如果你此刻能顺畅读到这篇同样托管在 GitHub Pages 上的文章，要么你的网络环境已经过关，要么链路正在恢复的路上。两者都不是坏事。