～技术宅真可怕～#1 - 2026-5-30 22:01
桜色 (我们所度过的每个平凡的日常，也许就是连续发生的奇迹。)
bangumi.one — bgm.tv的全域名镜像站点
由于一些不能说的原因，bangumi在内已经无法进行访问，这可是我上班摸鱼时候的宝藏小网站，不是很多时候都会有proxy环境，有一个能自由访问的镜像站点还是很有必要的，随即开始设置反代，但总感觉使用nginx反代显得繁琐而且功能不够灵活，比如在国内服务器上的镜像设置需要配置复杂的linux proxy chain。所以就想着能不能搓一个简单开箱即用的工具。
---
镜像域名
域名已接入 Cloudflare 自选优化，部分地区体验可能优于原站直连。
bangumi.tv 和 chii.in都是bgm.tv的镜像站看待，所以只反代bgm.tv即可
原站域名 → 镜像域名
bgm.tv → bangumi.one
api.bgm.tv → api.bangumi.one
lain.bgm.tv → lain.bangumi.one
fast.bgm.tv → fast.bangumi.one
next.bgm.tv → next.bangumi.one
doujin.bgm.tv → doujin.bangumi.one
开发者迁移提示：将代码中的 bgm.tv / bangumi.tv / chii.in 全局替换为 bangumi.one 即可。
---
mirrox 这个项目有什么不同
传统反代（Nginx / Caddy 的 proxy_pass）能做的事情其实很有限——它只转发请求，不管响应里写了什么。这导致反代站点上到处是漏网的原始域名链接，点一下就跳回去了，体验支离破碎。
Mirrox 的核心差异在于 HTTP 层 + Body 层的双重改写：
---
关于 Mirrox
开源地址：https://github.com/mirrox-dev/mirrox | MIT 协议
安全方面
任何的镜像反代都有同样的安全风险，bangumi.one 理论上可以获得你页面的所有内容，包括账号密码，如果实在放心不下，可以自己设置反代服务器，虽然我也不知道盗一个bangumi账号有什么用
---
如有访问问题欢迎反馈。
由于一些不能说的原因，bangumi在内已经无法进行访问，这可是我上班摸鱼时候的宝藏小网站，不是很多时候都会有proxy环境，有一个能自由访问的镜像站点还是很有必要的，随即开始设置反代，但总感觉使用nginx反代显得繁琐而且功能不够灵活，比如在国内服务器上的镜像设置需要配置复杂的linux proxy chain。所以就想着能不能搓一个简单开箱即用的工具。
---
镜像域名
域名已接入 Cloudflare 自选优化，部分地区体验可能优于原站直连。
bangumi.tv 和 chii.in都是bgm.tv的镜像站看待，所以只反代bgm.tv即可
原站域名 → 镜像域名
bgm.tv → bangumi.one
api.bgm.tv → api.bangumi.one
lain.bgm.tv → lain.bangumi.one
fast.bgm.tv → fast.bangumi.one
next.bgm.tv → next.bangumi.one
doujin.bgm.tv → doujin.bangumi.one
开发者迁移提示：将代码中的 bgm.tv / bangumi.tv / chii.in 全局替换为 bangumi.one 即可。
---
mirrox 这个项目有什么不同
传统反代（Nginx / Caddy 的 proxy_pass）能做的事情其实很有限——它只转发请求，不管响应里写了什么。这导致反代站点上到处是漏网的原始域名链接，点一下就跳回去了，体验支离破碎。
Mirrox 的核心差异在于 HTTP 层 + Body 层的双重改写：
- SOCKS5 / HTTP 代理：可按路由单独配置出站代理，上游连接走代理或直连均可灵活指定。
- 免去复杂的 nginx/caddy/apache 重写规则：使用 mirrox 配置好简单的 toml 配置，就可以一键启动一个镜像。例如: http://127.0.0.1:3000 -> https://bangumi.tv。直接实现重写输出，而非配置证书等 web 规则，本地都可以很方便的启动一个镜像地址供给调用
- 通配符路由：一条规则覆盖整个子域名，新增子域零配置。
- HTTP 层改写：自动处理请求的 Host / Origin / Referer，以及响应的 Location 跳转和 Cookie 域名，确保整个会话生命周期都留在镜像域名上。
- Body 层改写：对 HTML、CSS、JavaScript、JSON 响应体中的原始域名进行替换，真正实现页面内容级别的全镜像，而不是只换了个入口。
- 流式兼容：SSE、大文件、非文本资源直接透传，不做多余缓冲，不拖慢速度。
- DoH / DoT DNS：支持通过 DNS-over-HTTPS / DNS-over-TLS 解析上游域名，避免 DNS 污染和泄露。
- 严格 Host 白名单：未配置的域名请求直接返回 421，不会成为开放代理。
- WebSocket 代理：原生支持 WebSocket 连接升级与转发。
---
关于 Mirrox
开源地址：https://github.com/mirrox-dev/mirrox | MIT 协议
安全方面
任何的镜像反代都有同样的安全风险，bangumi.one 理论上可以获得你页面的所有内容，包括账号密码，如果实在放心不下，可以自己设置反代服务器，虽然我也不知道盗一个bangumi账号有什么用
---
如有访问问题欢迎反馈。
顺序
#10 - 2026-5-31 11:24
Escape0707
感谢 OP 做的贡献但是我觉得这个问题肯定算是经典问题了所以不是很清楚为什么不能用经典项目的既存技术来完成而是要用 Rust 写一个新的。于是我问（恶意诱导）了一下 GPT，以下是 GPT（按照论文答辩的审查姿态？）的回复我就不贴自己的回复了。（算是叠甲
我觉得这个项目的出发点可以理解：很多站点直接用普通反代确实会遇到链接、跳转、Cookie、Origin/Referer、静态资源域名等问题，最后体验不完整。所以“全域名镜像”这个需求本身不是伪需求。
但我对这个项目的技术路线还是比较保留。因为它解决的问题里，相当大一部分其实是经典 reverse proxy 场景里早就被讨论和解决过的问题。比如 Location/Refresh 跳转改写、Cookie domain/path 改写、Host/Origin/Referer 处理、响应体里的 HTML/CSS/JS/JSON 域名替换、WebSocket 转发、上游代理、白名单限制等，Nginx、Apache、Caddy、mitmproxy 这类成熟工具都已经有对应能力，区别主要是配置复杂度和封装方式。
所以我更希望看到的是：先论证为什么现有成熟方案不能高效解决这个问题，再说明为什么需要一个新的 proxy 项目。比如，Nginx + sub_filter / proxy_redirect / proxy_cookie_domain 不够在哪里？Caddy 加响应体替换模块不够在哪里？Apache mod_proxy_html 不够在哪里？mitmproxy 的 addon 模式不够在哪里？如果只是因为配置麻烦，那么更自然的方向也许是提供一套可复用的配置模板、配置生成器、Docker Compose 示例，或者基于成熟 proxy 的薄封装，而不是重新实现一个完整代理工具。
这点在安全和隐私上尤其重要。镜像站如果允许用户登录，运营者理论上就能接触页面内容、Cookie、账号密码输入、API 响应等敏感信息。越是这种场景，越应该优先选择成熟、经过长期使用和审查的基础设施。成熟工具的问题、边界、调试方式、社区经验都更清楚；新工具即使开源，也需要时间证明自己的正确性、稳定性和安全性。
另外，我觉得这类工具最好从一开始就强调“可自建”而不是强调某个公开实例。公开镜像实例当然方便，但它会把用户的信任集中到实例维护者、域名、服务器、网络链路和日志策略上。相比之下，如果项目目标真的是解决访问和镜像问题，那么最理想的形态应该是：任何人都能很容易自建，配置清楚，安全边界清楚，默认不记录敏感内容，部署方式可审计。这样用户不需要信任某个具体运营者，而是可以把信任转移到自己可控的基础设施和成熟组件上。
所以我不是反对“做工具”，而是觉得这个方向需要更谨慎地证明自己的必要性。现在看起来，它更像是把已有 reverse proxy 技术做了一次用途特化的重新包装，而不是一个本质上新的技术解法。作为个人项目当然可以做，但如果要推荐别人把登录态和敏感流量交给它，至少应该更充分地解释：为什么不用现有成熟方案，为什么新实现更安全、更可维护，以及用户该如何自建和审查它。
#10-1 - 2026-5-31 11:37
Escape0707
然后再喂给 GPT 项目源码以后：
看了项目源码之后，我觉得这个项目的出发点可以理解，但技术路线仍然值得保留意见。
它确实实现了一些实用功能：Host 白名单、Host/Origin/Referer/Location/Cookie Domain 改写、响应体文本替换、WebSocket 转发、HTTP CONNECT/SOCKS5 上游代理、Docker 部署等。这些都说明它不是单纯的玩具项目。
但也正因为看了源码，我更倾向于认为它的核心价值是“把经典 reverse proxy 能力重新打包成一个用途特化工具”，而不是提出了一个本质上新的技术解法。比如它的 HTTP 层改写、Cookie Domain 改写、Location 改写、响应体替换，本来就是 Nginx、Apache、Caddy、mitmproxy 等成熟方案长期覆盖的场景。如果现有方案只是“配置麻烦”，那更自然的路线可能是提供成熟 proxy 的配置模板、配置生成器、Docker Compose 示例，或者基于成熟组件做薄封装，而不是重新实现一个完整代理工具。
源码里也能看到一些早期项目特征。响应体改写主要是对 host 字符串做直接 replace，并不是 HTML/JS/CSS/JSON 语义级解析；DNS 配置虽然接受 udp/tcp/dot/doh，但实际 resolver 目前仍走系统 DNS；direct mode、TLS 监听相关字段也更像是预留，实际部署公网 HTTPS 仍然需要外部终止层，比如 Cloudflare Tunnel、Nginx 或 Caddy。这些都不一定是“错误”，但说明它距离一个可以放心承载登录态和敏感流量的成熟基础设施还有距离。
尤其是镜像站如果允许用户登录，信任模型就非常敏感。公开实例的维护者理论上可以接触页面内容、Cookie、输入内容、API 响应等信息。项目开源和支持自建可以缓解这个问题，但这也恰好说明：这类工具最应该强调的是可自建、可审计、最小化信任，而不是让用户默认信任某个公开镜像实例。
所以我不是反对有人写这样的工具。个人项目当然可以做，也可以作为学习或特定场景的轻量选择。但如果要把它推荐给普通用户，尤其是推荐大家把登录态交给它，我觉得需要更充分地说明：为什么不用现有成熟 reverse proxy 生态，为什么新实现更安全、更可靠、更容易维护，以及目前哪些功能仍然是早期状态或尚未完整实现。
#10-2 - 2026-6-1 00:09
桜色
因为Nginx的规则配置比较麻烦，一是没有原生支持proxy的方式，如果要使用代理就要配置去搞Proxychains劫持Nginx流量。
以及一些关于替换规则的定义需要频繁使用sub_filter进行替换，遇到写死在JSON js css类的文本没办法精确控制需要替换的文件大小，如果碰到大文件请求会很麻烦。
另一个就是不够开箱即用，Nginx就不是拿来做镜像的，比如我想要支持通配符子域名匹配的反代，proxy_pass是不支持的。
其他就是可拓展性了，我还想要一个新的todo，就是自动插入js脚本去做一些操作，在用Nginx这类工具的时候需要解析原网页结构然后用sub_filter去替换元素这样插入，曲线过河，不够优雅。
以及一些关于替换规则的定义需要频繁使用sub_filter进行替换，遇到写死在JSON js css类的文本没办法精确控制需要替换的文件大小，如果碰到大文件请求会很麻烦。
另一个就是不够开箱即用，Nginx就不是拿来做镜像的，比如我想要支持通配符子域名匹配的反代，proxy_pass是不支持的。
其他就是可拓展性了，我还想要一个新的todo，就是自动插入js脚本去做一些操作，在用Nginx这类工具的时候需要解析原网页结构然后用sub_filter去替换元素这样插入，曲线过河，不够优雅。
#10-3 - 2026-6-3 11:43
Escape0707
敢感谢楼主抽出宝贵的时间阅读并逐一回复的我质疑。这点我不知道我是不是理解错了，你说你要代理 nginx 的流量的意思是说你的镜像站服务器在国内是吗？还是什么特殊的情况。Nginx 没有原生支持代理的话可不可以配置 TProxy 解决？不知道楼主是否考察过类似方案。
另外楼主说的很多问题，不知道是不是问过前沿 LLM 不用自己重写代码就可以复用的现有技术的替代方案？我自己本人不是折腾前端和建站的专业方向，对这方便理解不是很深。不过我觉得给我更多的时间（还有金币）作为条件自己如果转职这个细分领域的工作的话，肯定会用 LLM 查询和验证自己的每一个技术决策，边做边学。所以我这次对于楼主的项目很多时候都是喂给 LLM 让他解释，然后对于他的解释不懂的地方进一步追问并提出质疑，最终总结成一份由 LLM 的知识背书、我自己的口味引导方向的质疑清单。楼主这次的丁宁回复我学习并和 LLM 交流/质疑了两轮，现在确实有一些质疑点。再在这里写的话有些太长太占用面板了。所以请允许我讲接触以 issue 的形式在项目 GitHub Repo 那边续发。
毕竟整个学习评判过程中使用了 LLM，我可以理解一些开发者对于 AI Slop 的反感，所以如果您介意这点的话直接无视或者 close 掉也完全没问题。因为我实在是要忏悔最近我一边实习一边找工作确实不是很能学习跟进楼主的项目，所以不能保证自己能对 LLM 的言论去粗取精之后完全用自己的话语提出质疑。但如果部分的意见能对您和您的项目有建设性的作用的话是再好不过了。
https://github.com/mirrox-dev/mirrox/issues/3
桜色 说: 因为Nginx的规则配置比较麻烦，一是没有原生支持proxy的方式，如果要使用代理就要配置去搞Proxychains劫持Nginx流量。
以及一些关于替换规则的定义需要频繁使用sub_filter进行...
一是没有原生支持proxy的方式，如果要使用代理就要配置去搞Proxychains劫持Nginx流量。
另外楼主说的很多问题，不知道是不是问过前沿 LLM 不用自己重写代码就可以复用的现有技术的替代方案？我自己本人不是折腾前端和建站的专业方向，对这方便理解不是很深。不过我觉得给我更多的时间（还有金币）作为条件自己如果转职这个细分领域的工作的话，肯定会用 LLM 查询和验证自己的每一个技术决策，边做边学。所以我这次对于楼主的项目很多时候都是喂给 LLM 让他解释，然后对于他的解释不懂的地方进一步追问并提出质疑，最终总结成一份由 LLM 的知识背书、我自己的口味引导方向的质疑清单。楼主这次的丁宁回复我学习并和 LLM 交流/质疑了两轮，现在确实有一些质疑点。再在这里写的话有些太长太占用面板了。所以请允许我讲接触以 issue 的形式在项目 GitHub Repo 那边续发。
毕竟整个学习评判过程中使用了 LLM，我可以理解一些开发者对于 AI Slop 的反感，所以如果您介意这点的话直接无视或者 close 掉也完全没问题。因为我实在是要忏悔最近我一边实习一边找工作确实不是很能学习跟进楼主的项目，所以不能保证自己能对 LLM 的言论去粗取精之后完全用自己的话语提出质疑。但如果部分的意见能对您和您的项目有建设性的作用的话是再好不过了。
https://github.com/mirrox-dev/mirrox/issues/3
#12 - 2026-5-31 21:19
#14 - 2026-6-1 00:03
没试过#15 - 2026-6-1 00:11
，没有cloudflare的缓存对镜像站的压力太大了，就算改程序将静态资源就算缓存在本地也不够流量费的。
