中国大陆访问 GitHub 的本地加速器 —— 免插件、免服务器、后台约 12MB。 clone / push / 网页 / Release 下载 / raw / 头像全场景加速，其余网站流量完全不受影响。 直连流量本机直达 GitHub 官方边缘；镜像链剥凭据，不外泄。
本机跑一个代理（127.0.0.1:7810）+ 管理页面（127.0.0.1:7811），只接管 GitHub 系域名：
- 不查 DNS：内置 GitHub 真实 IP 表（
routes.json），DNS 污染免疫 - 连不上就换：IP 按表逐个试，坏的垫底，单点故障只慢不掉
- TLS 指纹是 Chrome 同款：BoringSSL + 伪装 SNI，绕过针对明文域名的阻断
- 隧道握手首包分片：CONNECT 透传把 ClientHello 拆成 2~3 段（切点/间隔每连接随机）再发，DPI 拼不齐 SNI——真名腿免于 RST 的掩体（byedpi 同款思路，纯用户态，可 A/B 开关）
- 路由是二部图：IP 节点（伪装身份 + 校验锚点）× 域名行（策略开关）+ 实测边状态机——421 拉黑、超时降权、风控冷却、成功洗白，全部按 (IP, 域名) 精确记账；
docs/support等子域靠证书锚点并入伪装通道，不再需要专门的白名单腿 - 连接复用到极限：连接池按 IP 节点共享，一条 h2 连接混发多个 host 的流，每节点双通道冗余；GitHub 前端遥测本地拦掉（一个字节不发往上游）
- 大文件分片竞速：Release 附件 / 源码包按字节切段，直连与镜像链同台并行跑，慢段尾巴自动让给最快的那条（ECT 时间槽派发：手里的字节 ÷ 上一窗实收）；源码包域（codeload）不支持分段，走直连优先 + 校准链序；候选全灭才失败
- 双击
gitport-github.exe（或.\gitport-github.exe -tray驻留托盘） - 首次启动在 exe 同目录自动生成
ca.crt/ca.key、routes.json、settings.json—— 所有开关默认全关 - 打开工作台：先开「GitHub 分流接管」（写系统 PAC）→ 需要内容域直连/流式直通再开「MITM」（一键装证书根）
不开 MITM 也能用（纯透传加速）。系统代理接管在退出时自动还原；强杀残留由下次启动自愈。
| 做不到 | 原因 | 应对 |
|---|---|---|
| macOS / Linux | 系统代理、托盘、剪贴板全调 Windows API（winreg / WinInet） | macOS 推荐 Watt Toolkit / Clash Verge |
| 大文件上传快 | push 与单附件都是单流协议，一条 TCP 的吞吐就是天花板（本机实测约 119KB/s）；代码里没有限速，换链路会变 | 多附件并发；优先走 release 附件上传（本机实测直拨约 1.3MB/s） |
| 一劳永逸 | GitHub 边缘 IP 会迁移 | 种子补缺 + DNS 兜底腿自愈；极端情况手改 routes.json |
| 零门槛 | MITM 需装本地根证书 | WebUI 一键安装；不装也能用 |
| 加速所有网站 | 只路由 GitHub 系域名 | 其他站点用通用代理 |
| 带凭据查询串的请求不进镜像 | 签名/令牌串等价凭据，交第三方即外泄——剥空镜像仅派直连（同浏览器直答源站，零外泄） | release 附件/私库资产走直连腿正常下载 |
| raw/头像偶发被掐 | GFW 对 Fastly 内容边缘间歇阻断 | 内容域熔断 + 镜像链自动接管 |
| 透传遇会话级风控页会持续 | GitHub 对会话（cookie）标记后，垫底轮换会加速"会话-IP 漂移"，放大风控信号 | 切 MITM（连接池驻留、零 IP 漂移）或等风控过期 |
| schannel 系 CLI 走 MITM | 叶子证书无 OCSP/CRL，Windows 吊销检查硬失败 | curl --ssl-no-revoke；git 关 schannelCheckRevoke；浏览器无感 |
| 根证书只签 GitHub 域 | 签发前校验域名在受管表内，其他域名一律拒签 | 既是限制也是保护：装了这个根证书，也只有 GitHub 系域名会被解开 |
| 管理界面写接口要带标记头 | 防跨站伪造，无 Origin 的请求需带 X-GitPort-Request: 1 |
浏览器工作台无需处理；curl 调用加一个头即可 |
- push 大包慢？ push 是单流协议，一条 TCP 的吞吐就是天花板（本机实测约 119KB/s，代码里没有限速）；流式直通保证不 502，中断后整体重传。
- raw 偶发 6~8 秒？ 直连池到 Fastly 内容边缘间歇受阻（走的是伪装 SNI，真名 SNI 只用在白名单域名上，跟这里无关）；内容域熔断 + 镜像兜底已就位，自动恢复。
- 浏览器报证书风险？ MITM 开了但根证书未装/浏览器未重启；WebUI 一键装根后重启浏览器。
- 端口冲突？
.\gitport-github.exe -port 7812 -webui 7813。 - 页面显示「暂时不可用」？ 封锁窗口期，8 秒自动刷新，窗口一过即恢复。
.\gitport-github.exe # 桌面壳 + 托盘
.\gitport-github.exe -headless # 无窗口：只跑代理 + 管理页面
.\gitport-github.exe -tray # 驻留托盘（开机自启用）
.\gitport-github.exe -port 7812 -webui 7813 # 换端口- 工作原理 —— 请求全流程、二部图查询管线、边状态机、连接复用、镜像链、流式直通
- 连接池 v2 设计 —— 二部图与伪装统一建连的设计动机、openssl 实测证据、迁移记录
- 路由表（历史） —— v1 族路由时代的实测矩阵，判定逻辑已被 routes.json 取代，数据仍有参考价值
- 页面缓存 —— 缓什么/不缓什么、会话语义、分钥匙、骨架门、头像 302 记忆
- 高级配置 —— settings.json 键位契约、routes.json 手改指南、边状态机
- 术语速查 —— 网络与封锁名词大白话
前提：ninja.exe 与 nasm.exe 在 PATH 中。Ninja 在 VS BuildTools 的 ...\Common7\IDE\CommonExtensions\Microsoft\CMake\Ninja（默认不在 PATH，需要手动加一次），nasm 在 ...\nasm\nasm-<ver>。.cargo/config.toml 已选用 Ninja 生成器，并让 boring-sys 在 dev profile 下走 Release CRT——否则 VS 生成器会撞上 MSBuild 的 XamlTaskFactory 权限错误，dev 链接会缺 __imp__CrtDbgReport。
cargo build --release # 产物 target\release\gitport-github.exe
cargo test
cargo clippy --all-targets- 多站点加速（HuggingFace 等）：拨号引擎、串发表、镜像链均为数据驱动，扩服务 = 加数据不改代码
常见加速器是"多开连接多轰几遍"。这个项目每一层反过来，都在帮 GitHub 省资源——既是设计立场，也是它和同类工具的差别：
- 遥测拦截：GitHub 前端遥测占 api.github.com 约 75% 的请求（Datadog RUM / 心跳），本地直接读掉回 204，一个字节不发往上游
- 强制 gzip：客户端没要压缩的请求也按压缩要，少传字节
- 列表页缓存：只缓存搜索、issue/PR/commit/release 列表、通知这类"来回翻"的页面，外加这些页面拖着的那十几个计数/动态接口；连续浏览期间（导航间隔 ≤15 分钟）一直本地秒回，离开超过 15 分钟整盘清空、从零开始。仓库首页、文件浏览、详情、设置页一律不缓存——宁可每次回源，也不拿旧副本顶替。强制刷新用 Ctrl+F5（F5 会读缓存，最多是 15 分钟前的副本）。搜索页按 Accept 分 JSON/HTML 两把钥匙、
p=1归一化、限流骨架拒存——翻页和退出回列表第二次起全部秒回。细账见 页面缓存 - 首页骨架：
github.com/单独按 7 天寿命缓存——会变的部分（常用仓库、更新日志、拉取请求/议题、通知红点）全是独立接口，按上面的会话寿命走；壳不变，所以跨会话直接复用。仓库首页/o/r不在此列 - 头像入口 302 记忆：GitHub 的头像入口是「302 跳转 + no-cache」，浏览器每次渲染都要重问一遍跳转（260-310ms × 十几个并行）。代理记住跳转目标本地直答，浏览器行为不变、来回归零
- 数据层验活的串发拨号：没有后台定时全量测速（那种循环才是真给边缘添堵），IP 死活全凭真实请求验出来，失败即换、成功即驻留
只想填一个、不想挑：https://v4.gh-proxy.org
这是作者本机九个内容域实测下来最慢的一个，只放它，故意的：
- 快的镜像没必要再帮着宣传，公益服务扛不住白嫖流量；
- 愿意折腾的，工作台里支持填多个镜像：小文件链用「校准」按钮按响应头实测排位，大文件下载由代理按实时吞吐动态选家——链序不再决定谁被用；
- 嫌这个慢，随时删掉换别的，或者干脆自建一个 CF Worker（设置页有完整代码）。
工作台每个镜像旁有一个**「信任」勾选**，它决定 GitHub 302 落点 URL(带 sig/jwt 签名，下载工具分片续传常用这种形态)能不能交给该镜像：
- 未勾选(默认)：带签名的下载一律剥掉镜像、仅走直连——安全，但下载工具若恰好全用签名 URL 分片，大文件竞速会被锁死在单条直连链上；
- 勾选：签名 URL 也放行给该镜像参与竞速。
签名 = 一小时有效的提货凭证。交给第三方镜像，意味着这个小时内这个文件可以被它(及其日志)免登录重放下载。
所以：
- 自己部署的 Cloudflare Worker(代码在设置页)→ 可以放心勾——日志在你手里，没有任何第三方经手；
- 公益镜像(gh-proxy.org 等)→ 保持不勾，并且不要用它们下载私人仓库的 release 附件。公益镜像通常会记录请求 URL,私人附件的签名落在别人日志里，等于把那个小时里的这份私库文件交了出去(公共仓库附件无此顾虑——本来就是公开的)。
简单法则：下载的全是公共仓库 → 全勾，性能最好；要用私人附件 → 公益镜像别勾(或临时取消勾选)，自建镜像随意。
本项目默认使用的镜像链来自 gh-proxy.org 等公益服务。由于本工具直接调用接口，无法帮镜像站增加广告收益。如果您频繁使用镜像下载大文件，恳请您稍微花几分钟，去原网站关闭 AdBlock 浏览一下页面，或者给站长捐赠一杯咖啡。如果您有条件，请一定优先在 routes.json 中填入您自建的 CF 节点。
如果 GitPort GitHub 帮到了你，点个 Star ⭐ 就是最好的支持——它能让更多人看到这个项目。
- 仅供学习网络原理与个人自用提速，遵守所在地区法律法规，后果自负
- 与 GitHub 无任何隶属关系；第三方公共镜像可用性随其变化