1. 踩坑与破解记录#

[!CAUTION] 血泪结论 面对这类商业网盘的云端风控规则，所有试图通过技术手段绕过限速和流量计费的折腾基本上都是浪费时间，充钱才是最快、也是唯一的正解（要不就闲鱼买个日vip）。

2. 最终拿到的数据成果#

list_CN_Android.zip     15.16 GB    共 9243 个 zip 包

中途在多线程分块下载时还踩了 parget 工具的一个坑：在重试断点续传时，程序未重新计算 start offset，导致莫名多下了 190 MB 垃圾数据。排查修掉该逻辑后，只对损坏的 part04 进行了重下，最终完成了 CRC 校验 9243 / 9243 全部通过。

改造流程#

flowchart TD
    A[原始 APK 母本] --> B[apktool 解包]
    B --> C[修改 Smali 字节码中的服务端 IP]
    B --> D[解包 assets/AppAssets.zip]
    D --> E[libhonoka 解密 server_info.json]
    E --> F[修改 domain / cdn_server 配置]
    F --> G[libhonoka 重新加密]
    G --> H[压缩回 AppAssets.zip]
    C --> I[apktool 重新打包]
    H --> I
    I --> J[uber-apk-signer 签名 v1+v2+v3]
    J --> K[最终客户端 LLSIF_CN_patched.apk]

1. 反编译解包：使用 apktool 解包 APK 安装包；
2. Smali 补丁：定位并修改 Smali 代码中写死的原厂服务器 IP 与握手地址；
3. 修改核心配置文件：
   • 目标文件位于 assets/AppAssets.zip 内的 config/server_info.json；
   • 注意：该文件是高强度加密的二进制格式，必须借助 libhonoka 提供的专用解密/加密模块处理；
   • 踩坑点：Emscripten 编译出的模块必须通过 waitReady() 循环轮询 M.calledRun 完成运行时加载，且 Emscripten FS 内部文件路径必须使用相对路径，否则加解密直接落空崩溃；
4. 重打包与重签名：使用 apktool b 重新构建 APK，并使用 uber-apk-signer 完成 v1 + v2 + v3 全版本签名对齐。

服务保障与底层优化#

• 守护进程：编写 systemd unit 文件托管 honoka-chan，支持挂掉自启、开机加载与平滑重载；
• TCP BBR 拥塞控制：由于服务器部署在海外（中美跨洋链路），丢包率和延迟相对敏感。在 Linux 内核开启 BBR 算法，实测为长链路资源下载提供了关键的吞吐优化。

事故 1：玩家卡在「通信中 / 下载失败」#

• 故障现象：客户端首次登录时，界面长时间转圈，随后弹出通信失败，无法获取资源列表。
• 排查根因：源码中的 ForceAllUsersRelogin() 函数在每次服务启动时，都会无条件对全局所有账号打上 force_relogin = 1。中间件 common.go:73 检测到该标志后，直接拦截并将所有 main.php/* 请求返回 404，导致客户端完全拿不到下载清单。
• 修复方案：将强制重登改为仅在真正发生破坏性数据结构迁移时触发；对已受影响的账号执行：
  sql

  UPDATE user_pref SET force_relogin = 0;

• 技术教训：在服务端启动流程中，任何「无条件全局执行」的迁移或重置代码都是定时炸弹。

事故 2：卡面与角色立绘全部 404#

• 故障现象：玩家成功进入游戏后，卡面立绘、按钮图标大面积白板，服务端日志中客户端连打 86 次 /static/Android/extracted/... 全部返回 404。
• 排查根因：原教程文稿中特别强调过「除了 archives 压缩包，还需要另外维护一份解压后的静态资源目录」。初始搭建时疏忽了这句，导致服务器根本不存在 extracted/ 目录。
• 修复方案：编写自动化脚本，将 9243 个 zip 包全量解压到 extracted/ 目录，生成 221,846 个文件 / 占盘 11.3 GB。
• 次生灾害：首次解压完成后，惊现 5129 个文件大小变成了 0 字节！
  • 深度排查发现：资源包中 type 99 是增量更新包，里面包含 5245 个 0 字节的占位条目；
  • 解压时文件名按自然序排列，type 99 排在最后解压，把前面 type 0~6 解压出来的真实非空资源全部覆盖成了空文件；
  • 增加「跳过 0 字节条目」解压过滤规则后重新解压，0 字节异常文件彻底归零。

事故 3：开启 gzip 压缩导致客户端「发生连接错误」#

• 故障现象：为了优化全卡牌列表（单次响应高达 1.8 MB）的传输速度，在 Gin 路由层挂载了 gzip 压缩中间件。上线后，玩家在点击进入“社员”页面时瞬间报错闪退。
• 排查过程：编写了针对中间件的独立单元测试，压测验证流完整性与 Content-Length，确认后端中间件逻辑完全符合 HTTP 标准规范。
• 真相大白：抓取服务端原始报文日志发现：
  text

  21:16:49  [AE] 客户端 Accept-Encoding = "gzip,deflate"

  客户端的 HTTP 网络库虽然在 Header 里大张旗鼓地声明了支持 gzip，但在接收到经过 gzip 压缩的二进制流后，游戏原生引擎底层根本没有做解压处理，直接拿压缩乱码去解析 JSON，进而导致反序列化崩溃！
• 处置方案：在配置文件中果断关闭 gzip：
  json

  "gzip_enabled": false

• 技术教训：客户端「声明支持」≠「真能支持」。服务端按规范行事的老实人最容易吃大亏。

事故 4：试图用 Cloudflare 边缘加速游戏 API —— 弄巧成拙的负优化#

• 设想方案：游戏 API 每次请求耗时约 1 秒左右（因为客户端每次调用都新建连接，跨洋 TCP 握手 + TLS 协商要跑 3 个 RTT）。设想将 API 域名挂载到 Cloudflare，利用 Anycast 节点就近完成 TCP 握手，预期将握手延迟压缩至 ~310ms。
• 实施操作：修改客户端 server_info.json，把 API 域名指向开启橙云（Proxy）的 CF 域名。
• 实际结果：不仅延迟没有降低，反而变得更慢，且频繁发生随机丢包与断连。
• 处置方案：全面回退所有改动，cdn_server 彻底切回 VPS 直连 IP。
• 结论定性：海外廉价 VPS 环境下，Cloudflare 仅适用于 Web 网页展示与静态大文件下载；用于加速游戏协议 API 属于纯粹的负优化，永久移出备选池。

事故 5：模板手滑导致服务端直接 panic 瘫痪#

• 故障现象：在修改 css.html 前端模板时，错误地使用了文本替换：
  javascript

  s.replace('{{ end }}', ...)

  把 Go 模板语法闭合标签 {{ end }} 意外删掉了。服务重启时直接抛出恐慌：
  text

  panic: template: css.html:187: unexpected EOF

  服务端直接挂死，全站访问 502。
• 修复方案：补齐模板末尾闭合标签。
• 长效防范：Go 模板 static/templates/** 是在程序启动时一次性载入内存编译的，任何语法错误都会导致进程直接起不来。为此在自动化部署链路中增加了离线模板预检脚本：每次更新代码前，先用 html/template 对全部 19 个模板进行离线语法 Parse，只有 19/19 全部通过后才允许执行 systemctl restart。

资源占用情况#

[!NOTE] 性能定论 基于 Go 构建的服务端，中美跨太平洋的物理信道带宽与延迟，是唯一的性能短板。

自动化自检跑分：

python3 selftest_e2e.py

测试结果：10 通过 / 0 失败，所有链路全绿。

1. 核心网络与管理配置#

服务端口       : 51400（honoka-chan 直连监听）
生产域名       : https://sif.shiro.team（443）
管理后台       : https://sif.shiro.team/admin
玩家个人中心   : https://sif.shiro.team/me/login
客户端下载     : https://sif.shiro.team/download
管理员白名单   : config.json 中的 admin_phones 配置

2. 常用排障与运维指令#

• 重启服务：
  bash

  systemctl restart honoka-chan

• 端到端健康自检：
  bash

  python3 selftest_e2e.py

• 慢接口排查日志：
  bash

  grep SLOW-API service.log

• 抓取客户端声明的编码格式：
  bash

  grep '\[AE\]' service.log

• 安全重启前连接检查（避免打断正在下载大型资源包的玩家）：
  bash

  ss -tin state established '( sport = :51400 )' | grep -c bbr

折腾完了。这个小小的怀旧角落，就这样在公网稳稳地跑起来了。 原视频：【【教程】LLSIF1 国服私服（本地服）搭建教程】 https://www.bilibili.com/video/BV1Fk4y1S7HA/?share_source=copy_web&vd_source=e703c525c3faf0b743827824b4f80504 感谢UP主 梦路_YumeMichi 提供的服务端与资源