mirrorproxy

关于

MirrorProxy 是一个使用 Rust 开发的高性能、自托管、多生态镜像代理平台。 它将 GitHub、Docker/OCI、npm、PyPI、Cargo、Go Modules、Composer、Maven、NuGet、RubyGems，以及 Linux/BSD 操作系统软件仓库统一到同一套代理核心中，并提供 Web 管理后台、流量统计、缓存、配额和跨平台改源客户端。 简单来说： 以前每种包管理器都要寻找不同镜像站，现在只需要部署一个 MirrorProxy。 它解决了哪些痛点？ 1. 软件源又多又乱 开发环境往往同时依赖： GitHub Release 和源码仓库 Docker Hub、GHCR、Quay npm、Yarn、pnpm pip、PyPI Cargo、Crates.io Go Modules Composer、Packagist Maven、NuGet、RubyGems Linux 发行版软件仓库 每个生态都有不同的配置格式、镜像地址和回滚方式。换一台电脑、重装一次系统，就要重新配置一遍。 MirrorProxy 用一套服务统一处理这些协议。 2. 公共镜像不可控 第三方镜像站可能随时出现： 同步延迟 服务限流 地址变更 镜像下线 缺少特定生态 无法查看真实流量 无法配置自己的上游和访问策略 MirrorProxy 可以部署在自己的服务器上，节点、带宽、缓存、上游和配额全部由自己控制。 3. GitHub 下载和 Git 依赖经常超时 MirrorProxy 不仅能代理 GitHub Release、Raw 文件和源码压缩包，还支持 Git Smart HTTP Clone。 独立客户端可以自动配置 GitHub HTTPS URL 重写： mirrorproxy set github --base-url 之后使用： 的 Git Clone 和包管理器 Git 依赖，会自动改走 MirrorProxy，无需手动修改每个项目的依赖地址。 4. 改源容易，恢复困难 很多改源脚本只负责写入配置，却不关心用户原来的内容。一旦配置出错，恢复只能靠手工处理。 MirrorProxy 客户端提供带保护的操作： mirrorproxy set cargo --base-url mirrorproxy reset cargo 写入前记录原始配置，重置时精确恢复；如果文件在改源后被其他程序修改，还会拒绝静默覆盖。 5. 自建代理最怕失控 一个没有边界的下载代理很容易变成： 开放代理 SSRF 入口 带宽黑洞 凭据泄漏点 磁盘无限增长器 MirrorProxy 从设计上限制代理目标： GitHub Host 白名单 软件仓库固定路由 路径穿越检查 Hop-by-hop Header 过滤 私有凭据隔离 全局请求限流 月度流量配额 有容量上限的磁盘缓存 请求统计和审计日志 它不是简单的 URL 转发器，而是一套面向软件分发场景设计的受控代理平台。 核心功能 多生态统一代理 当前已经覆盖： GitHub 仓库、Raw、Release、Archive 和 Git Clone Docker Hub、GHCR、Quay、Kubernetes Registry Composer / Packagist npm / Yarn / pnpm pip / PyPI Cargo / Crates.io Go Modules Maven Central RubyGems NuGet v3 CPAN、CRAN、Hackage Rustup、Julia、LuaRocks NVM / Node.js、opam Clojars、CocoaPods Pub / Flutter、Anaconda / Conda TeX Live、WinGet、GNU ELPA Nix、Guix、Flatpak、Homebrew Debian、Ubuntu、Fedora、Arch Linux、Alpine、openSUSE、Void、Gentoo、OpenWrt、ROS 等操作系统软件仓库 一套 MirrorProxy，基本覆盖现代开发环境最常用的软件分发链路。 独立跨平台客户端 服务端和改源客户端完全分离： mirrorproxy-server：代理服务和 Web 管理后台 mirrorproxy：轻量级改源客户端 客户端支持： Windows macOS Linux 并提供类似 chsrc 的简洁命令： mirrorproxy list mirrorproxy get npm mirrorproxy set npm --base-url mirrorproxy reset npm Web 管理后台 服务端内嵌 React Web 控制台，无需单独部署前端。 可以管理和查看： 已启用代理 上游地址 流量统计 月度配额 请求限流 磁盘缓存 管理员密码 配置审计 CLI 命令生成 镜像源目录 首次启动会生成随机管理员密码，密码仅以 Argon2 哈希形式保存。 流式传输，适合大文件 MirrorProxy 默认采用流式转发： 不把大型软件包完整读入内存 支持 Range 请求 保留必要的 ETag 和缓存头 下载流量按实际发送字节统计 Docker Blob、GitHub Release 和系统软件包均可持续流式传输 即使面对大型镜像和安装包，也不需要用服务器内存硬扛。 可控磁盘缓存 缓存默认关闭，启用后具备明确边界： 只缓存成功的公开 GET 响应 可限制单对象大小 可限制缓存总容量 自动执行 LRU 淘汰 Authorization、Cookie、Range 请求自动绕过缓存 大文件和未知长度响应保持流式转发 不用担心代理运行几天后把磁盘悄悄塞满。 流量统计与月度配额 MirrorProxy 使用 SQLite 保存： 每日请求量 每个代理目标的流量 错误数量 月度总流量 配额剩余量 请求诊断事件 可以配置月度上限： [quota] enabled = true monthlygb = 500 timezone = "Asia/Taipei" onexceeded = "stopproxy" 达到上限后只停止代理请求，Web 后台、健康检查和管理接口仍然可以访问。 部署非常简单 使用 Docker Compose： MIRRORPROXYPUBLICBASEURL= docker compose up -d 或者直接运行容器： docker run -d \ name mirrorproxy \ restart unless-stopped \ p 3000:3000 \ e MIRRORPROXYPUBLICBASEURL= \ v mirrorproxy-data:/data \ kudang/mirrorproxy:latest 检查服务： curl 生产环境建议放在 Nginx、Caddy 或 Traefik 后，通过 HTTPS 对外提供服务。 为什么值得推荐？ MirrorProxy 最吸引人的地方，不只是“支持的软件源多”，而是它把原本碎片化的镜像加速问题变成了一套完整产品： 一个服务统一多个软件生态 一个客户端完成跨平台改源 配置可以安全回滚 Web 后台集中管理 流量和缓存都有明确边界 默认防止开放代理和凭据泄漏 Rust 单体服务，部署成本低 SQLite 默认持久化，无需额外数据库 提供真实包管理器和操作系统仓库验证矩阵 它非常适合： 网络访问不稳定的开发者 家庭实验室和自托管用户 中小团队内部软件源 CI/CD 构建节点 教育网和企业内网 多服务器统一下载出口 希望掌控带宽和缓存成本的运维团队 Roadmap：星火志愿镜像网络 MirrorProxy 还规划了一个更有野心的方向——星火计划。 未来，社区运营者可以自愿贡献公网 MirrorProxy 节点： 通过 spark-mirrors.sina.dev DNS TXT 获取核心 Bootstrap Peer 使用 libp2p Kademlia 发现志愿者节点 根据延迟、健康状态、容量和成功率自动选择节点 节点故障时自动切换 使用签名身份和短期公告防止伪造节点 保留 MirrorProxy 的白名单、安全策略和流量限制 为了保证网络质量，志愿者节点必须具备： 稳定的公网域名 公共可信的 HTTPS 证书 可从公网访问的开放端口 可配置的带宽和流量配额 星火计划明确不考虑 NAT、CGNAT、Relay 或打洞节点，把精力集中在可靠、可验证、真正能够承担软件分发流量的公网服务器上。 一句话总结 MirrorProxy 把 GitHub、容器镜像、语言包管理器和操作系统软件仓库，统一成了一套可以自己掌控的高速软件分发入口。 如果你受够了下载超时、改源脚本、镜像失效和重复配置，MirrorProxy 很可能就是那个“部署一次，长期省心”的开源项目。

收录记录

1. 阮一峰周刊·用户投稿

   2026年7月17日 · 1 次收录