GitPort GitHub —— GitHub 加速器

中国大陆访问 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 + 伪装身份 + 校验锚点），右边是域名（策略开关），中间靠节点的 hosts 声明"谁服务谁"；另外每对 (IP, 域名) 还有一套实测状态——421 拉黑、超时降权、风控冷却（成功只洗前两种，风控到期自愈），全部按边精确记账
• 连接复用到极限：连接池按 IP 共享，一条 h2 连接混发多个 host 的流；同一个 IP 永远只有一条通道，第二个 host 撞上只会复用或换 IP，不会并存两条；主通道只开新 IP，副通道先捡现成的、捡不到才跟着串发；候选有两个以上空 IP 才开第二条通道（分落两个 IP），只有一个就老实单通道，不硬凑；host 分三类：内容域开双通道、按「空闲且快」选；会话域单通道、建连优先自己拨一条；大文件域和那些不值得养专属通道的子域（只去 Fastly 边缘的 docs、support、resources、desktop、pages、skills、archiveprogram、socialimpact、raw.github.com、agent，加上超低频的 uploads、api.mcp，共 12 个）也是单通道，但复用现成的优先、自建兜底
• 大文件分片竞速：Release 附件按字节切段，镜像一家一份、直连一份（大文件域单通道，不再给两片），并行拉；下载器同时发好几个 Range 时，把这些在途区间的字节加起来除以「镜像数 + 1」算出每段大小，大区间先占段位、小区间保底一段，不会每个请求都把全部镜像打满；文件再小也不设最小尺寸，照样按段位切；慢段尾巴自动让给最快的那条（ECT 时间槽派发：手里的字节 ÷ 上一窗实收）；候选全灭才失败。源码包（codeload / /archive）不支持分段，走主站池单流

1. 双击 gitport-github.exe（或 .\gitport-github.exe -tray 驻留托盘）
2. 首次启动在 exe 同目录自动生成 ca.crt/ca.key、routes.json、settings.json —— 所有开关默认全关
3. 打开工作台：先开「GitHub 分流接管」（写系统 PAC）→ 需要内容域直连/流式直通再开「MITM」（一键装证书根）

不开 MITM 也能用（纯透传加速）。系统代理接管在退出时自动还原；强杀残留由下次启动自愈。

ips 是"能用得上的出口清单"，一条记录就是一个出口（或一段同族的出口）。想加一条线路，往这里加一条即可：

{
  "ip": "140.82.112-114.3-4",
  "sni": "baidu.com",
  "verify": "github.com",
  "hosts": ["github.com"],
  "latency": {"140.82.112.3": 580, "140.82.112.4": 553}
}

两条规矩：

• 域名只在一边写。hosts 块只写"有特殊策略"的域名（比如 content / fallback: mirror）；普通域名靠节点的 hosts 声明就够了，程序启动时会自动补回，落盘时也把它们省略。所以看不到某个域名不代表它没被代理。
• 两边的对应关系。节点声明了某个域名、hosts 块没写 → 启动时自动补一行默认配置，所以文件里看不到它；反过来，hosts 块写了某个域名、却没有任何节点服务它 → 这个域名没有出口，请求直接走兜底。

• push 大包慢？ push 是单流协议，一条 TCP 的吞吐就是天花板（本机实测约 119KB/s，代码里没有限速）；流式直通保证不 502，中断后整体重传。
• raw 偶发 6~8 秒？ 直连池到 Fastly 内容边缘间歇受阻（走的是伪装 SNI，真名 SNI 只用在白名单域名上，跟这里无关）；内容域熔断 + 镜像兜底已就位，自动恢复。
• 浏览器报证书风险？ MITM 开了但根证书未装/浏览器未重启；WebUI 一键装根后重启浏览器。
• 端口冲突？ .\gitport-github.exe -port 7812 -webui 7813。
• 页面显示「暂时不可用」？ 封锁窗口期，8 秒自动刷新，窗口一过即恢复。
• 双击 exe 没反应？ 若旧实例界面已死（托盘无图标、窗口出不来），它会收到点击后自动退出，新实例约 2 秒内接管；若旧实例还活着，会弹「已在运行」提示——去看系统托盘。

.\gitport-github.exe            # 桌面壳 + 托盘
.\gitport-github.exe -headless  # 无窗口：只跑代理 + 管理页面
.\gitport-github.exe -tray      # 驻留托盘（开机自启用）
.\gitport-github.exe -port 7812 -webui 7813   # 换端口

• 工作原理 —— 请求全流程、二部图查询管线、边状态机、连接复用、镜像链、流式直通
• 路由表 —— 分流判定全流程、边状态机、兜底与熔断；文末附录是 v1 时代的实测存档
• 页面缓存 —— 缓什么/不缓什么、会话语义、分钥匙、骨架门、头像 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 无任何隶属关系；第三方公共镜像可用性随其变化