其实网站被镜像这件事情,本身没什么稀奇的,如果想搭建一个镜像网站,从零开始也不过个吧小时的时间。
之所以写这个东西,是因为最近有看到好几个人被镜像的,这一个(爱娃子),还有 这一个(我是军爸)。
不过,既然还有人有疑惑,那就简单的教一下大家怎么来镜像个网站吧。
为此,我创建了一个开源项目:
OpenResty + OpenCC 反向代理简繁转换
基于 OpenResty 反向代理上游站点,对 HTML 正文 做 OpenCC 简繁转换(默认:简体 → 繁体,配置文件为 s2t.json)。适合在不改源站的情况下,为访客提供另一种字体习惯版本。
功能概览
| 能力 | 说明 |
|---|---|
| 反向代理 | HTTPS 回源(示例站点:zhongxiaojie.cn),客户端走本机证书与域名。 |
| HTML 简繁转换 | 仅当 Content-Type 含 text/html 时对整页做 OpenCC UTF-8 转换。 |
| gzip 解压 | 通过 Lua zlib 尝试解压响应体(与去掉 Content-Encoding 的配合视上游行为而定)。 |
| 链接与图片 URL 保护 | 转换前将 href / src / poster / data-src / srcset 及裸 http(s):// 链接替换为占位符,转换后还原,避免路径或查询串中的汉字被改写导致 404。 |
| IPv4 优先解析 | resolver … ipv6=off + 变量 proxy_pass,减轻云主机无 IPv6 时对 AAAA 连接失败的问题。 |
| 静态资源直过 | 图片、CSS、JS、字体等扩展名单独 location,不做 OpenCC,减轻负担、避免误伤二进制。 |
| 动态库加载 | 对 libopencc.so 按常见路径依次尝试 ffi.load,降低找不到共享库的概率。 |
限制与说明
- JSON / JS / CSS 内嵌字符串若不在上述保护规则内,仍可能被转换;重要数据建议不要用全文 HTML OpenCC 硬转。
- 内联样式
style="background:url(...)"未单独做保护,若遇少数破图可再扩展规则。 - 转换配置在
nginx/opencc/opencc-filter.lua中的OPENCC_CONFIG(默认/usr/share/opencc/s2t.json);若需 繁体 → 简体 可改为t2s.json等(需系统已安装对应 OpenCC 数据文件)。
目录结构(仓库内)
├── README.md # 本说明
├── zero.zhongxiaojie.cn.conf # 示例 server 配置(域名、证书路径请按环境修改)
├── nginx/opencc/opencc-filter.lua # body_filter:缓冲、解压、保护 URL、OpenCC、输出
└── fix.md # 库路径 ldconfig 备忘
部署要求
- OpenResty(带
lua-nginx-module)。 - OpenCC 运行时:系统安装
libopencc.so与词典数据(如/usr/share/opencc/*.json),并保证 worker 进程能加载到.so(见下文「共享库」)。 - Lua 可
require('zlib')的模块(用于zlib.inflate,若无 gzip 体则pcall失败会跳过解压,不影响后续逻辑)。 - 上游为 HTTPS 时,本机需能解析并访问该域名(已用
resolver时 VARIABLE 形式proxy_pass才会走指定 resolver)。
部署步骤
1. 安装 OpenCC 与数据文件
以 Debian / Ubuntu 为例(包名因发行版略有差异):
sudo apt update sudo apt install -y libopencc1.1 opencc # 或 libopencc2 等,以仓库为准 或者手工复制 lib64目录下的文件到 脚本对应的路径就是这个 /usr/lib64
确认存在词典,例如:
ls /usr/share/opencc/s2t.json
2. 确保能找到 libopencc.so
若日志出现 libopencc.so: cannot open shared object file:
- 将库放在系统默认搜索路径,例如 Ubuntu amd64:
-
ldconfig -p | grep opencc
-
若库仅在
/usr/lib64等非默认路径,可执行(与仓库fix.md一致): -
echo '/usr/lib64' | sudo tee /etc/ld.so.conf.d/usr-lib64.conf sudo ldconfig
- 或在 OpenResty 的 systemd 单元 中设置
Environment="LD_LIBRARY_PATH=/usr/lib64:/usr/local/lib"后重启。
脚本内已对多路径做了 ffi.load 尝试;仍失败时请对照 ldd 与 opencc 包实际安装位置排查。
3. 部署 Lua 脚本
将 nginx/opencc/opencc-filter.lua 复制到服务端约定路径(与 nginx 配置一致),例如:
sudo mkdir -p /usr/local/openresty/lua sudo cp nginx/opencc/opencc-filter.lua /usr/local/openresty/lua/opencc-filter.lua
按需修改脚本顶部 OPENCC_CONFIG 指向本机实际的 JSON 配置。
4. 合并 Nginx / OpenResty 配置
- 将
zero.zhongxiaojie.cn.conf中的server块纳入主配置(include或粘贴到nginx.conf的http {}下)。 - 修改 证书路径、日志路径、上游域名
zhongxiaojie.cn、以及body_filter_by_lua_file的路径,使其与当前环境一致。 header_filter_by_lua中去除Content-Encoding,便于对明文 HTML 做处理;若上游与解压逻辑不匹配,需自行观察是否需要调整。
5. 校验并重载
sudo /usr/local/openresty/nginx/sbin/nginx -t sudo /usr/local/openresty/nginx/sbin/nginx -s reload # 或 systemctl reload openresty
6. 验证
- 浏览器访问你的站点,查看页面简繁是否符合预期。
- 检查 图片与站内链接是否正常(尤其含中文或
%编码的路径)。 error.log中不应再出现 OpenCC 库加载失败或大量 IPv6 unreachable(在无 IPv6 环境)。
配置项速查
| 项目 | 位置 |
|---|---|
| OpenCC 配置 JSON | opencc-filter.lua → OPENCC_CONFIG |
| Lua 脚本路径 | zero.zhongxiaojie.cn.conf → body_filter_by_lua_file |
| 上游站点 | set $upstream_host … 与 proxy_pass https://$upstream_host$request_uri |
| DNS / 仅 IPv4 | resolver 223.5.5.5 8.8.8.8 valid=300s ipv6=off |
| 不参与转换的静态文件 | `location ~* .(gif |
故障排查
| 现象 | 可能原因 |
|---|---|
libopencc.so 找不到 |
未安装包、ldconfig 未包含库目录,或需 LD_LIBRARY_PATH |
body_filter 报错、栈指向 ffi.load |
同上;或架构不一致(如 32/64 位混用) |
| 上游连接 IPv6 失败 | 已用 ipv6=off + 变量 proxy_pass;仍失败则检查防火墙与 DNS |
| 图片 404 | 历史上多为 OpenCC 改了 URL 内汉字;当前脚本对常见属性已做保护,若仍有个别,检查是否来自 CSS url() 或 JS 动态拼接 |
如需改为其他域名、证书路径或 t2s 转换方向,只需改配置文件与 OPENCC_CONFIG,无需改 OpenResty 核心。
实际效果:
预览地址:https://zero.zhongxiaojie.cn
开源项目地址:https://gitee.com/obaby/baby-website-mirroring-tool
参考链接:https://blog.csdn.net/wzj_110/article/details/127758020
https://blog.rexskz.info/support-traditional-chinese-using-openresty-and-opencc.html




3 comments
这么热乎的教程啊,赞👍
你这个图点一下,再点一下,页面就跳到首页去了?
强大到可怕。。。
这些人镜像你们博客干嘛,他们那边访问太慢了,还是被 qiang 了?不理解啊