Nginx：TLS、日志轮转与平滑发布

维护Nginx 静态站与代理前先保存主配置、conf_prefix、Host/SNI 和上游地址，恢复后以同一请求的状态、上游目标与访问日志验收。具体配置见配套示例。

前置是完整配置。维护对象不仅是nginx.conf，还包括include、静态产物、证书、密钥、运行用户和日志。这里给理论流程，未发送信号、未握手、未轮转文件，也未执行配置检查。

TLS证书、SNI与信任链

Nginx TLS配置使用listen ... ssl与TLSv1.2 TLSv1.3；TLS1.3还依赖所链接OpenSSL能力。ssl_certificate需要服务器证书及正确中间链，不是CSR；ssl_certificate_key必须对应私钥。名称覆盖、有效期和信任链由客户端检查，禁用验证会隐藏错误。私钥不进公开root、仓库、访问日志或示例输出，仅必要进程可读。官方SSL模块

示例nginx-tls.conf是完整替代主配置，要求读者准备certs/lab-fullchain.pem与certs/lab-key.pem；未知SNI的默认server用ssl_reject_handshake拒绝。TLS默认参数放http层，避免握手选择默认站点时意外启用旧协议。更换证书后需要检查再reload，已建立的连接可能继续使用旧会话；证书自动续期必须有失败告警和到期检查，证书续期账户与权限需单独配置。

示例只在本机教学HTTP上游。真正跨机器的HTTPS上游还需proxy_ssl_server_name on、正确proxy_ssl_name、proxy_ssl_verify on及可信CA文件，不能因客户端入口是HTTPS便认为中间链路已加密认证。旧站点TLS配置的TLSv1/TLSv1.1与ssl on保留作历史阅读，不作生产基线。cipher策略需按目标客户端、密码库与组织基线评估；不照抄一份过时套件列表。

访问日志、请求号与隐私

Nginx 日志分为记录请求结果的access_log和记录配置、连接、文件错误的error_log。示例JSON访问日志使用escape=json，把$uri、状态、request_time、upstream_addr、upstream_status、connect/header/response_time记录为字符串。无上游或未取得某阶段时间时可能是短横线；多次尝试时上游字段可能包含列表，不能直接当一个浮点数解析。

Nginx request_time覆盖请求整体处理时间；upstream_response_time是上游阶段，connect_time与header_time用于定位建立连接和首部等待。它们不能直接相减就认定应用CPU时间。示例用$uri省去查询串，但内部重定向后它可能变成应用壳路径；确需还原原始目标时应设计脱敏字段，不能盲目记录$request、Cookie、Authorization或带token的$request_uri。路径本身也可能含个人信息，要按业务脱敏及保留周期管理。

Nginx 请求号由入口$request_id生成并传给上游，客户端响应也得到同一号，可关联访问日志与应用日志；请求号仅用于追踪，不是认证令牌。默认拒绝server没有site里的响应头，不承诺所有请求都有客户端请求号。error.log仍可能记录请求目标，需同样保护。JSON转义避免日志结构被换行破坏，但不是隐私治理。官方日志模块

reload、quit与失败回退

Nginx reload向master发重载信号，master检查新配置并尝试打开日志、监听等资源；成功则启动新worker并让旧worker优雅退出，失败则保留旧配置继续服务。语法正确不能保证证书可读、端口可绑定或业务路由正确；reload成功也不代表每个请求已切换到新worker。

读者未来发布顺序是保存可恢复配置和静态产物、检查完整include、使用相同prefix与-c检查、发送reload、核对error.log和请求行为，再决定完成。长连接或流式响应可能延长旧worker退出；应在发布预算里考虑，不立即把旧worker存在判为泄漏。若路由错误但重载成功，应恢复旧文件并再次检查重载；不能等待master自动判业务失败回退。quit优雅退出，stop快速停止，二者不是无损保证。官方进程控制

日志轮转与reopen

Nginx reopen在日志文件改名后重新打开日志；只改文件名时旧worker仍持有原文件描述符，所以看到新文件空白不一定是没流量。读者应由自己系统的轮转机制执行归档、设置正确所有者和reopen，再检查实际写入目标。reload也可能重新打开文件，但不应用改配置流程替代明确的轮转机制。

不默认使用copytruncate：复制与截断间存在竞争，可能丢记录。先按磁盘、保留时间和敏感级别定义轮转，再验证用户权限；磁盘写满会同时影响日志和代理临时文件，不能只删error.log应急。示例专用logs目录由读者管理，不改系统日志策略。

超时、上传、连接与容量

Nginx client_max_body_size限制请求体大小，示例1m超限预期413；这不是把client_body_buffer_size调大就能消除的错误。client_body_timeout是相邻读取间隔，不能保证恶意慢速客户端的总占用有界。代理缓冲可能写临时文件，容量规划要同时看磁盘空间、inode、打开文件数和上下游连接。

缓存不是缓冲：proxy_buffering不表示跨请求复用响应。要启用proxy_cache需另设计缓存键、鉴权隔离、Cookie、失效和绕过策略；本例不缓存API。静态长缓存应绑定内容hash文件名与可回退发布，不能给可变index.html随意加一年缓存。容量、缓存、压缩和HTTP/2/3应依据真实负载验证。

运维练习与参考解答

练习：reload退出码为0但浏览器仍看到旧页面，应该证明哪些事实？

参考解答：先确认命令针对哪个prefix/PID、master是否记录新配置生效、请求是否命中正确地址Host、文件是否属于同一root，再看客户端/中间缓存与旧连接。不要反复stop/start掩盖问题。保存变更前后配置和日志，才能区分发布失败、路由错误和缓存旧内容。

旧站点配置的可迁移机制与撤回项

Nginx stream 是否等于 HTTP 代理，CSR 能否作为服务器证书？ 旧 HTTP/HTTPS 多站点配置可归为监听与名称匹配、静态文件路径、外部跳转、反向代理、上传限制和四层转发。server_name 不替代 DNS、证书名称或访问授权，root 与 proxy_pass 是不同内容处理方式。0.0.0.0 可用于绑定却不应当成明确的上游目标；应写实际可达地址，并确认容器/主机命名空间。URI 替换是否发生取决于 proxy_pass 是否含 URI，详见机制篇。

旧 TLSv1/TLSv1.1、ssl on、把 CSR 配到 ssl_certificate、写死旧密码套件与业务绝对路径的示例撤回为新部署模板。TLS 终止不证明后续上游加密，证书、私钥、SNI、链与客户端信任需分别核对。HTTP 到 HTTPS 跳转宜使用已批准的固定目标，不把任意来访 Host 无条件拼进跳转；若应用有写方法，还须按方法保持要求选择状态码，而非只复制 rewrite permanent。

stream 中的 proxy_pass 转发 TCP/UDP 层流量，与 http/location 的代理指令不是同一上下文；映射数据库端口不会替数据库加认证或 TLS。旧 stream 片段没有完整模块/上下文与权限方案，因此不作为完整数据库发布配置。client_max_body_size 是请求体限制，50M 仅为旧案例值，413 也可能由其他入口或应用产生，不能只调缓冲参数。

旧 CentOS7 RPM 源安装顺序与默认路径表撤回为跨平台安装保证，先确认实际主配置、prefix、模块与运行用户。reload、quit、stop、reopen 的生命周期由本篇对应节承接。403 应逐级检查父目录搜索与文件读取、运行用户和强制策略；不能递归 chmod 755/777 代替定位。两份来源已合并过的重复信号和配置不再重新发布。