同行程序的更新记录里写着切换 HTTPS 和屏蔽缓存投毒，算不算安全修复

同行程序的更新记录里写着切换到 HTTPS 和屏蔽缓存投毒，这两项算不算安全修复？答案是分层的：屏蔽缓存投毒那一条写明了「缓存文件被当作 PHP 执行」，属于安全修复；把模板外链由 http 改为 https 那一条写的是避免混合内容拦截，属于页面正确性修复。同一份版本记录里的改动并不都在同一个层次上，读发布说明时要按「修的是哪一层」分类，而不是看它出现在哪一版里。

发布记录里哪三类改动容易被混谈

以这份按周推进的发布记录为样本，可以把常被并列提及的改动分成三类。

三类的判断标准很简单：改动是否关闭了一个可被利用的入口。关闭入口的是安全修复，只是让页面表现符合预期的是正确性修复。

传输加密解决的是链路不是站点

把模板里的外链改成 https，影响的是浏览器在加载这个页面时会不会拦截非加密资源。它解决的是页面在加密访问下的显示问题，不改变站点自身对外暴露的入口。

这一点常被误读：发布说明里出现 https，就以为整站传输链路被加固了。实际要区分三段——访客到站点的链路是否加密、站点内部引用的资源是否加密、站点与后端服务之间的链路是否加密。改模板只落在第二段上。

判断自己站点是否受影响，做法是把页面源码里的资源引用逐条看一遍：只要还存在非加密的外部资源引用，浏览器就可能拦截；这与站点是否被攻击是两件事。

缓存投毒与缓存正确性的边界

缓存本身出问题不一定算安全问题，边界在于错的东西被缓存之后还能做什么。

这份记录里那条修复写得很具体：前台参数编码与查询分隔符的绕过会让 HTML 内容被投毒进缓存，并且缓存文件会被当作脚本执行。前半段是正确性——访客读到别人的页面；后半段才是安全——缓存目录里的文件进入了执行路径。所以它应当作为安全修复对待，优先级排在纯显示类改动之前。

同类的问题还可以自查两处：缓存键是否把不该参与缓存的参数算进去，缓存文件所在目录是否允许被直接请求执行。两项都关上的站点，缓存投毒才只是脏数据而不是执行入口。

可信代理为什么和安全修复放在一起

另一条修复写的是无条件信任转发请求头，导致 IP 黑白名单与登录锁定可被绕过，处理方式是新增可信代理配置。

这类问题的实质是：程序把请求头里的地址当成访客来源，而这个头可以被随意伪造，于是所有基于来源地址的限制都会失效。它属于访问控制层，与加密无关，也确实属于安全修复。

部署结构决定这条改动是否影响自己：站点前面有反向代理时，需要显式声明哪些代理地址可信；前面没有代理时，把可信代理清单留空更稳妥，否则任何人都可以构造一个转发头来影响程序对来源地址的判断。

升级前的备份与回退清单

按周推进的发布节奏意味着升级机会经常有，但每轮升级前先做两件事：备份与回退确认。AnQiCMS 的备份与恢复支持数据以及静态文件的备份和恢复，这一项在缓存类修复上尤其关键——修复常伴随缓存键变化，旧的静态产物需要能整批回退。

部署方式也会影响复验范围。AnQiCMS 支持宝塔面板一键部署、aaPanel、LNMP 命令部署与 Docker 镜像几种方式，默认监听 8001 端口；无论哪种，反向代理与缓存规则都配在站点外层，程序升级本身不会替你把外层规则改对。

常见问题

版本记录里出现 https 就说明站点安全了吗？

不能这样推。它通常只说明模板里的资源引用被改成了加密形式，解决的是浏览器拦截问题；站点自身是否加密要看访客访问的实际链路。

缓存投毒修复与普通的缓存清理有什么区别？

区别在后果。清理只影响性能与新鲜度，而记录里那条修复涉及缓存文件被当作脚本执行，属于执行路径问题，应按安全修复安排优先级。

没有用反向代理，需要配可信代理吗？

不需要，而且建议留空。可信代理清单的意义是限定哪些地址转发来的来源信息可以被采信，没有代理时任何转发的请求头都不应当被采信。

每周都有新版本，要不要每次都跟？

按分类跟。带执行风险与访问控制的修复应当尽快；加密、样式与第三方库的版本刷新可以排到维护窗口。跟之前先完成备份与回退确认，升级才算可逆动作。