Nginx在10月14日发布1.30.6与1.31.7两个维护版本，一次修掉五个安全漏洞。三个属于内存访问类问题，评分最高的一项达到9.2。
评分描述后果，不描述难度
9.2分对应的是内存被破坏之后可能造成的后果，评分只衡量后果，不衡量触发难度。这五个漏洞都需要特定配置才能走到出问题的代码路径：加载了哪些模块、请求经过哪些处理阶段、上游返回什么内容，条件不成立时请求到不了那一行。评分的计算方式本身就假定了最坏情况可达，实际能不能打到，取决于配置。同一个版本号，两套配置的风险并不一样，共用一套漏洞清单没有意义，逐条对自己的配置才是有效动作。
先确认是否在受影响范围内，再决定升级窗口。需要查两件事：编译参数里带了哪些模块，配置文件里用了哪些指令。公告每个条目都写了受影响模块，两边一对就能判断，不需要读源码。
反向代理、重写规则、静态文件缓存这几类配置覆盖面最广，也是这类漏洞常见的触发位置。把第三方模块编译进来的实例要额外核对，官方公告的修复提交只覆盖官方模块，第三方模块的问题需要看各自的仓库。分发版打包的Nginx还要看补丁状态，Debian、Ubuntu、CentOS的维护者通常会把补丁回移到旧版本，只对比上游版本号不够。
升级窗口怎么排
确认受影响之后，升级是替换二进制并重载，中断时间在秒级。多台实例滚动升级时，逐台摘流量、替换、reload、回填，单台的中断可以做到用户无感。
分支选择上，1.30.6属于稳定分支，1.31.7属于主线分支，生产环境一般跟稳定分支。不能立即升级的，可以先用配置层规避：关掉用不到的模块、限制触发路径的访问来源、在WAF侧拦掉对应的请求特征。这类措施依赖对触发条件的准确理解，公告没读透不宜把它当主要防护。配置层的改动只是把请求挡在触发条件之外，配置一调整就可能重新暴露，能真正解决问题的动作只有替换二进制。跨大版本升级时，先确认中间版本有没有配置项改名或废弃，配置对照表列出来再动手。
维护版本通常不引入行为变化，升级风险低于功能版本。仍建议在预发环境跑一遍核心业务路径，重点是反向代理与重写这类与请求处理相关的配置，静态资源与接口两条链路各验一次。reload之后看一下worker进程是否全部换新，旧进程残留会让补丁形同未装，这处细节常被漏掉。
升级后要看的告警
内存类漏洞的共同表现是进程异常退出或内存被改写，对外呈现为502、连接重置、偶发崩溃，日常监控里容易被当成上游服务不稳定。升级之后这类告警消失，反过来印证了此前的影响判断。告警没有变化也不代表之前就不受影响，只是触发条件没有凑齐，别把没报警当成没风险。升级前后把告警数量拉出来对一次，比只看有没有新增更可靠。
申请创业报道，分享创业好点子。点击此处，共同探讨创业新机遇！
