网站首次访问跳转成人页面：恶意 Nginx 植入的排查与修复

2026 年 10 月 6 日左右，我在部署、使用 yuanxing.dreaum.cn 时发现：网站第一次打开会跳到成人页面，再打开却可能正常。随后发现，多个指向香港云服务器的子域名都有类似情况。10 月 6 日是我首次观察到异常的时间，不能据此认定那天才发生入侵。

这次排查确认，恶意代码藏在生产 Nginx 的可执行文件中。10 月 11 日已完成程序替换，并让加载旧程序的进程全部退出。修复后的源站响应检查与浏览器抽样均未再发现已知植入的注入标签或恶意请求。不过，最初入侵入口、替换时间和操作者仍未确定，整台服务器的可信状态也还需要进一步恢复。

从网页响应定位到恶意程序

最初的困惑是，网页源文件里找不到跳转代码。有些请求出现异常，有些又完全正常，容易让人怀疑浏览器缓存、DNS 或第三方资源。突破口来自多个站点返回的 HTML：它们都多出了一段伪装成 jQuery 的外部脚本标签。相同内容还出现在旧 Nginx 工作进程的内存里，最终在可执行文件中找到了对应的混淆数据与响应过滤逻辑。

这意味着，注入发生在 Nginx 返回响应的过程中，不必逐个改动磁盘上的网页。多个网站共用同一套 Nginx，就会一起受影响。恶意模块按 HTML 类型、设备标识、来源地址、时间和概率筛选请求，因此一次访问正常、服务器本机访问正常，都不足以证明程序安全。

脚本怎样制造首次访问现象

标签引用的域名为 js[.]cdndelivr[.]org，这里已做失活处理，请勿访问。它用近似名称伪装成常见 CDN，加载的内容也并非正常 jQuery。对捕获样本进行静态解码后，发现它先检查设备与页面条件，再读取浏览器本地保存的上次跳转时间：没有记录，或者已超过 8 小时，才会跳到 hqpd[.]m0u2w[.]top。

这个时间记录按站点保存，所以不同子域名可能各自触发“首次”跳转；超过 8 小时也可能再次发生。它解释了为什么重复测试容易看起来恢复正常。本次没有执行恶意脚本，也没有访问后续落地站，因此未还原最终成人页面的完整导航链。捕获样本中的跳转分支针对移动设备，也不足以解释当时遇到的所有电脑端历史现象；远程脚本可能变化，缺少当时的完整抓包仍是证据缺口。

能还原的植入过程与未知入口

溯源时，安装日志、保留的编译产物和备份互相对应：原安装产物使用 GCC 11.4.0 / OpenSSL 3.5.4，而受污染生产文件使用 GCC 5.4.0 / OpenSSL 1.1.1w+quic，文件大小、哈希和模块也明显不同。这些证据强烈支持“正常源码构建安装后，生产文件被另一份恶意程序替换”。但这些历史记录都曾保存在受污染主机上，缺少外部签名快照，因此不能把它写成已经掌握完整替换过程。

恶意文件还保留了与干净备份相同的修改时间。文件日期可以被保留或重新设置，不能直接当作感染日期。现有日志没有记录能够与二进制写入对应的完整命令，无法确定是谁、在什么时候、通过什么入口完成了替换。登录记录也与运维工具日志交叉核对过；有些短连接属于正常后台探测，未能对应的记录仍保持“未确认”，没有仅凭时间相近判定攻击者。

我也核对了“是否是 Nginx 1.30 或以下版本漏洞”的猜测。版本号需要结合具体漏洞、模块和配置条件判断，受污染程序展示的版本字符串更不能保证真实补丁状态。当前没有证据证明某个 CVE 就是本次入口。可以确定的是，人为植入了额外的注入、隐藏命令执行和外联能力；这些能力存在，并不等于已经查明它们实际执行过哪些命令或外传过哪些数据。

从可信源码替换并复测

修复先保留证据，再从官方渠道取得源码并核验签名，在独立目录重新构建 Nginx 1.30.5 / OpenSSL 3.5.9。必要的第三方模块经过核对和兼容验证，候选程序先用现有配置进行隔离测试，通过后再切换生产程序，并确认所有加载旧恶意文件的进程退出。此次处理同时移除了已确认植入，并更新安全版本。

验收使用保留原域名的 Host 与 TLS SNI、绕开公共 CDN 差异的源站访问路径。180 次请求中，174 次收到 HTTP 响应，检查到的响应均没有已知注入；其中 6 次为 502，另有 6 次证书校验失败，均未算成业务通过。浏览器抽样未发现已知恶意请求或外站导航；一次超时保留在记录中，随后博客的 6 次重试全部返回正常页面。这些测试包含设备 UA 模拟，不能替代真实手机与微信的全部场景验收。