前天晚上，很多微信群都在发一张 PHP 漏洞截图，几乎是“史诗级”灾难场景，可能影响全球 70% 以上 Web 服务器，看到后，我立马登陆自己手头各个服务器查询，看看影响范围到底有多大。
结果这一修，就花了两个晚上时间。一直到昨天晚上 1 点多才搞定。
但其实这个修复过程，主要问题也不在 PHP 身上。
本以为只是打个补丁
2026 年 10 月 21 日，PHP 官方发了两个严重漏洞，CVE-2026-109618 和 CVE-2026-109619，业界叫它 php2shell，CVSS 评分 9.2，不用登录就能远程执行代码。修复版本是 8.5.12、8.4.27、8.3.36、8.2.35，≤ 8.1 没有任何补丁。
我手里有几台 VPS，跑着 1Panel 和一堆 Docker 应用。第一反应就是按官方指引升级 PHP 运行环境。结果一操作才发现，我的 1Panel 版本太老，而且很多组建都被自己魔改过，折腾起来实在有点痛苦。最终还是下个决断，先把 1Panel 升到最新版吧。
这就是一切麻烦的起点。
升级 1Panel 的痛苦过程
大部分机器升级还算顺利，使用官方发布的 1panel-migrator 大概几分钟就行了。但有一台 VPS，存储已经占了 80%，快照做不了，迁移又要把大量文件搬来搬去，空间根本不够。升级过程反复失败，直接导致这台 VPS 上 30 多个站点丢得只剩 7 个。
后来我才发现，其中一个 FreshRSS 应用就吃了 50GB，里面全是文章缓存和附件，好几年没清理过；还有一个老站点挂了大约 70GB 图片，也是导致升级失败的原因。
然后一看远程备份，哦豁，老早前就备份失败了。这才发现，因为我设置远程备份到 Onedrive 会员几个月前到期后没续费，容量从 1TB 降回 15G，新文件一直无法写入。
这一折腾，导致我又额外花了一个晚上来处理这台 VPS 上的站点修复问题。这也是为啥一个简单的“打补丁”能折腾我两个晚上的原因。
其实升级 1panel 甚至是修复 PHP 漏洞这种事情，本身并不复杂，复杂的是我过去几年在服务器上慢慢堆出来的这些东西。
毕竟，在修复前，我曾对手头所有机器扫过一遍，总共 100 来个 Docker 容器，加一些系统级服务，实际上 PHP 项目只有 14 个，典型的就是博客、图床、RSS阅读器和个人自建的 PHP 项目。甚至于同一天出现的 Node 高危漏洞影响还更广些，我几乎每台 VPS 上都装了 Node 环境。
那些没人维护的容器
1Panel 自带的 PHP 运行环境还算好处理，新建环境、切换站点就行。真正麻烦的是那些从第三方应用商店或者不知猴年马月前从哪拉取的一些个人开发项目，很多都是几年没更新过了，而老版本 PHP 直接打包在应用自己的镜像里，没有统一的运行环境可以切换。
手动改这些容器，意味着要进 docker-compose.yml 改 image: 标签、确认新镜像里 PHP 版本达到修复线、重建容器、验证站点正常、还要处理数据卷和配置的兼容性。十几个容器逐个来，一个晚上根本不够。
最后我是借助 DeepSeek Harness 来辅助完成这部分修复的。它帮我梳理了每个容器的镜像来源、当前 PHP 版本、可用的修复标签，以及重建时需要注意的挂载和网络配置。手动操作从“逐个进容器排查”变成了“确认方案后批量执行”，省掉了大量来回试错的时间。
这个过程本身也说明，这次漏洞的修复成本，已经高到需要借助 AI 工具才能赶在被人攻击前处理完。而攻击者那边，批量扫描和自动化利用早就是常态。攻防两端的工具都在加速，个人用户夹在中间，靠手工维护服务器的模式会越来越吃力。
这套东西不是一天堆出来的
说实话，看到那 100 多个容器的时候，我自己也有点恍惚。它们不是一天冒出来的，是二十年一步步走过来的。
20 年前，我最初只需要一个域名、一台虚拟主机就够用了。后来觉得虚拟主机功能太单一，限制又多，开始用上廉价 VPS。
廉价 VPS 嘛，总是有这种那种短板，要么硬盘小，要么带宽小，要么线路不行，要么性能不行还超售严重。于是就开始研究怎么搭配，大盘机存东西，线路机跑流量，性能机跑计算，几台机器组合着用。
组合着用，就得接触 CDN 分流、多域名反代。手头的 VPS 一多，探针面板、集群管理、分散备份就得上了。然后各台 VPS 也不能闲着，能多跑个服务就跑个。
长年累月下来，正经业务没搞几个，各种稀奇古怪的伪需求倒是不断增加。
而人的精力总是有限的，你不可能一直记得所有事情。就像这次我发现 Onedrive 会员过期，原因是我需要多个 Onedrive 账号来备份数据，而日常我用的那个账号绑定在 Windows 系统上一直正常，所以压根没想过另一个账号过期的事，毕竟之前一次续费就是几年。而当时设置提醒功能，定时发邮件的那个收件邮箱也在年前被 Google 删掉了。
本质上，这就是一个单一系统向复杂系统增熵的过程。 每加一台机器、每多一个反代、每装一个“反正闲着也是闲着”的容器，系统就更复杂一点，需要维护的东西就更多一点，面临的网络安全风险也就更大一点。
到这次 PHP 漏洞爆发，熵增的账单终于寄到了我手上。
维护业务还是在维护服务器？
修完这次漏洞，我就在想，搞这么折腾，这到底这是在维护业务还是在维护服务器啊。
如果一台 VPS 上跑的东西，大部分是自己偶尔用一下的工具、测试完就没再打开的项目、以及记不清用途的容器，那么每一次漏洞爆发，我都要为这堆东西买单，盘点、停用、找镜像、重建、验证、处理存储不足、处理迁移失败。
而这些东西本来就不应该占着公网端口，也不应该进入我的“应急修复清单”。
所以对个人用户来说，方向其实很清楚，能交给平台的，就别自己养服务器。
Cloudflare Workers、Vercel 这类 Serverless 平台，把运行时、补丁、扩容、可用性都接过去了。你不需要在漏洞爆发那天去 docker pull 一个新镜像，也不需要因为存储 80% 而升级失败。最近几年，已经有大量独立开发者从分散的 VPS 集中迁移到 Vercel Cloudflare Workers 这类平台，原因不只是省钱，还有“不再担心流量突增导致 CPU 超限”和“不想再为基础设施擦屁股”。
像我日常用的最多的 Cloudflare 的 Workers + R2 + D1 全栈方案在边缘场景下的性价比也确实明显更高，虽然有每天 10 万次请求限制，我也经常收到日用量告警提醒，但讲起来也只是多注册个免费账号的事情。
当然，这也不是说 VPS 没有价值。在需要持久化进程、自建数据库、特定内核参数的东西，VPS 仍然是合理的选择。但“什么都往一台 VPS 上装”的时代，对个人来说正在结束。
我昨晚在一个技术群里提出，就 2026 年当下，对个人用户来说，其实1台家里云主机+1台线路机就足够，就引发了不少人共鸣。
下一步计划
经过这次教训，算是又上了一课，与其等所有事情失控集中爆发，不如源头上“精简”。特别是像我这样，都中年人了，记性没那么好，能少一事少一事，也算是未雨绸缪。总结一下大概有这些方向。
第一，把“用完就没第二次”的容器和 DNS 记录清出去。 不急着删，先停掉、标记、观察一段时间。攻击面少一条，下次漏洞爆发时就少一个要判断的对象。
第二，能上 Serverless 的静态站和轻应用，逐步迁走。 不需要 SSH、不需要补丁、不需要担心 PHP 版本。个人博客、文档站、简单的 API，都属于这一类。
第三，留在 VPS 上的，只留真正需要常驻的东西。 并且给每个数据型容器设保留策略，FreshRSS 那种 50GB 的教训，一次就够了。
第四，接受“漏洞会越来越多”这个前提。 目标不是零漏洞，是高危入口不裸奔，出事能快速止损。容器化已经帮我限制了影响面；下一步，是让更多东西根本不需要我去修。
第五，用好 AI Agent。安全漏洞千奇百怪，今天应用层，明天系统层，我们永远不知道下一个高危漏洞是在哪出现，修复难度又几何，对麻烦难搞的，尽量让 AI 上，本质上都是机器跟机器打交道的事情，就别让人去花太大精力了。
第六，承认熵增是默认方向，做减法需要刻意。 系统不会自己变简单。每加一台机器、每装一个服务之前，先问一下自己，这个东西是不是真的需要常驻？还是我只是“反正机器闲着”？