Nginx

请检查 Tengine 上游主动健康检查的配置及节点摘除、恢复行为。结合所提供的工程和业务证据开展检查；资料不足时先列出影响结论的关键问题，可以推进的部分标注假设。不要编造文件、日志、测量结果或已完成的操作。

适用边界：适用于已确认包含 ngx_http_upstream_check_module 的 Tengine。该模块文档说明默认未启用、需要构建时加入；不能把其指令直接用于任意 Nginx。以实际构建参数、配置语法检查和运行行为确认兼容性。

输入：Tengine版本与构建参数；现有upstream和站点配置；健康接口契约；业务可用性与恢复目标；故障演练条件；监控及状态页访问范围。

核对主动检查模块的 interval、rise、fall、timeout 等参数。TCP 检查偏向连接可达性，HTTP 检查依赖响应状态，默认将 2xx 和 3xx 视为成功；结合检查状态展示确认实际行为。按项目实际版本解释规则，不机械沿用旧示例。

执行步骤：
1. 确认当前运行的程序、构建参数和已加载配置是否一致，再验证模块指令可用性。缺少模块时输出差异和替代方案评估需求，不编造现有环境已支持，也不要未经评审提出直接替换运行程序。
2. 定义健康接口代表的是进程存活、接流量就绪还是关键依赖可用，说明与业务请求的关系。TCP 能建立连接不能证明业务可用；HTTP 端点需明确 Host、路径、请求方法及预期状态，防止命中错误虚拟主机。
3. 检查健康请求是否被重定向到登录页、默认页或维护页。由于默认成功范围包含 3xx，必须结合接口契约限定成功状态并验证实际响应；只返回 200 的静态页也不能自动证明依赖和业务处理正常。
4. 根据实际响应时延和允许的误摘除、恢复时间评估 interval、timeout、rise、fall，并说明连续失败和连续成功的判断。用受控测试测量实际摘除和恢复耗时，不简单把示例参数或算术估计当成时限保证。
5. 验证启动时默认状态、单节点失败、全部节点失败和间歇抖动的行为，记录新请求分配与用户实际结果。节点摘除不代表已在途请求立即取消；重试策略另行核对写请求幂等性，不能用健康检查保证重试安全。
6. 在允许窗口逐个制造失败和恢复，复核状态页、上游统计及业务探测是否一致。状态页沿用现有受限入口或访问控制，不增开公开端口；验收后恢复演练配置，保留观察证据和可回退的配置版本。

输出：给出模块适用性结论、健康接口契约、配置变更建议及各参数理由；用场景表列故障注入、预期摘除或恢复、观测指标、实测结果和通过条件，并单列尚未验证的业务边界。

来源核验日期：2026-09-08。
- 阿里巴巴 / Tengine《ngx_http_upstream_check_module 主动健康检查》：https://github.com/alibaba/tengine/blob/f9c9f759c029dec42ad855141fa7f0c24e9a671e/docs/modules/ngx_http_upstream_check_module_cn.md

验证说明：已核对上述公开来源及具体规则或能力；本模板尚未通过模型对比实验或线上业务实测，不能以来源品牌、仓库热度或扫描分数代替验收。

来源许可说明：BSD-2-Clause。本条为中文原创整理，来源内容与本模板补充要求已在正文区分。

请审查 业务场景 的 WebSocket 接入，输出与现有网关及客户端兼容的配置和验收方案。

输入：WebSocket 入口和上游 连接地址；Nginx 与 SDK 版本 版本清单；代理层级 代理拓扑；心跳与重连约定 协议约定；当前配置和断连日志 现场资料。

1. 区分业务信令、文件上传下载及音视频媒体流，明确哪些请求经过此 Nginx。不要认为建立 WebSocket 就代表媒体通道或文件访问也已成功。
2. 追踪客户端握手到上游响应，核查路径、Host、认证和 Origin 判断。对于使用 HTTP/1.1 升级的链路，检查代理协议以及 Upgrade、Connection 的处理，并验证实际握手结果。
3. 为普通 HTTP 与长连接路径分别评估配置，避免无差别覆盖全站请求头。若使用腾讯云 IM，核对 SDK 版本和其对应代理域名；自有服务保留自己的域名与鉴权协议。
4. 结合业务心跳间隔和各代理的空闲超时定位断连。列出每层超时的含义，检查客户端是否在后台、弱网或网络切换时停发心跳；超时值依据实际约定确定。
5. 评估连接上限、文件描述符和单实例容量，使用测试环境的测量结果给建议。检查滚动发布时如何排空旧连接，以及重连后是否会重复执行有副作用的消息。
6. 验证握手失败、认证过期、正常消息、空闲保持、异常断开、重新连接及多实例发布。逐项记录连接状态、消息是否重复或丢失、恢复耗时和用户可见反馈。

输出：链路与超时对照、最小配置、断连原因证据、可复现测试步骤及容量待验证项。示例中的进程数、运行用户和网络地址不能直接迁入生产。

依据与范围
- [腾讯云 · IM 应对网络访问限制实践教程](https://cloud.tencent.com/document/product/269/122408)
核验日期：2026-09-08。依据公开资料改写的执行模板；原文是腾讯云 IM 接入示例；不照搬 root 用户、固定 worker 数量或示例网络地址。

请为 业务系统 设计能排查真实接口问题的 Nginx 日志和指标，兼顾查询效率与敏感信息保护。

输入：现有日志样例 日志样例；接口清单和路由规则 接口规则；观测平台 日志平台；业务成功定义 成功口径；流量规模与保留要求 容量要求。

1. 核查字段是否能串联入口、上游与应用，包括时间、请求标识、方法、规范化路径、状态、上游地址及耗时。标明各字段的类型、单位、时区和缺失值处理。
2. 按业务接口归并动态路径，避免订单号和用户编号造成维度无限增长。区分静态资源、健康检查、业务请求与内部调用，不让健康流量稀释失败率。
3. 对状态码、耗时分位数、请求量及流量分布分别定义分子、分母、时间窗与样本边界。HTTP 200 与业务成功要分开，不能由网关单独推断业务事务完成。
4. 根据真实日志编写最少量查询示例：失败最多接口、慢接口、指定请求轨迹以及变更前后对比。使用 SLS 时核对索引和查询语法，使用其他工具时给等价实现，不混用语言。
5. 设置基于历史基线、持续时间和最小样本量的告警候选条件。分别处理低流量误报与突发流量影响，说明告警后第一步应查看哪一段链路；没有基线时先给采样计划。
6. 检查 URL 参数、认证头和日志正文中的凭据及个人数据。制定必要字段脱敏、留存、访问权限和磁盘轮转方案，并以一条真实脱敏请求验证端到端检索。

输出：字段字典、指标口径、查询样例、告警条件建议和验证结果。所有百分比与阈值注明数据依据，不虚构流量统计。

依据与范围
- [阿里云 · 采集 Nginx 访问日志进行网站情况分析的案例](https://help.aliyun.com/zh/sls/collect-and-analyze-nginx-access-logs/)
核验日期：2026-09-08。依据公开资料改写的执行模板；SLS 查询语法不能直接当作本地日志命令；指标口径需按业务定义。

请定位 故障时间段 内 受影响接口 出现的 502/504，优先找到证据，再提出最小恢复动作。

输入：部署拓扑 链路拓扑；访问与错误日志 脱敏日志；最近变更 变更记录；上游健康和资源数据 运行指标；复现请求 请求样例。

1. 对齐各节点时区与故障窗口，记录用户症状、入口响应和影响比例。先确认实际链路是否包含 CDN、负载均衡和多层 Nginx，不能仅凭响应页面判断出错层。
2. 关联同一请求的入口状态、上游状态、连接与响应耗时。区分 Nginx 无法连接、上游返回错误、上游关闭连接和等待超时；日志缺少字段时明确证据缺口。
3. 从实际代理节点核对 DNS、目标协议、端口、路由、防火墙、监听地址与 Host。分别解释拒绝连接、静默丢包及 TLS 握手异常可能产生的现象。
4. 结合应用日志查看线程池、数据库连接池、外部依赖、内存和重启记录。寻找同时间的饱和、锁等待或超时传播，不把所有 504 归因于 Nginx 超时参数。
5. 比较最近版本、配置、证书和网络策略变更。为每个候选原因给支持证据、反证、只读验证方法及影响范围；先处理最可能且可验证的原因。
6. 给恢复动作及停止条件，说明对在途请求和数据一致性的影响。修改后复测同一请求，观察约定窗口并核对业务结果；问题消失但根因未证实应分别记录。

输出：故障链路图、事实时间线、候选原因表、恢复与回退方案、修复前后指标对照。没有证据支持时不要批量重启服务，也不要宣称已找到根因。

依据与范围
- [阿里云 · CDN 回源异常排查](https://help.aliyun.com/zh/cdn/user-guide/back-to-origin-troubleshooting)
核验日期：2026-09-08。依据公开资料改写的执行模板；原文针对 CDN，排查时应先确认实际是否有 CDN 层。

请审查 Nginx 到业务服务的完整请求链路，定位路由冲突和代理配置问题，给出与当前环境一致的修改。

输入：入口域名与请求样例 入口请求；Nginx 完整相关配置 网关配置；前端路由和 API 前缀 路径约定；上游地址与监听范围 服务拓扑；是否包含 CDN、负载均衡或 OSS 外围组件。

1. 画出浏览器到实际服务的路径，注明每跳协议、端口、Host 和 URI。先识别已有配置继承和 location 匹配关系，再判断命中的站点。
2. 分别跟踪首页、前端深层路由、API、上传与静态资源。用具体请求展示转发前后 URI，核查 proxy_pass 路径及末尾斜杠是否符合接口契约，避免把接口错误转成前端首页。
3. 检查上游 Host、HTTPS SNI 和原始协议的传递。使用 OSS 时按其域名要求验证；普通 Java、Python 服务按实际虚拟主机约定处理，不机械复用 OSS 示例值。
4. 明确可信代理名单和真实客户端地址的来源。审查应用对转发头的信任边界，避免直接信任公网客户端伪造的地址或协议头；检查认证信息是否被不必要地复制到第三方上游。
5. 根据实际响应规模、并发、上传和业务超时确定连接复用及缓冲策略。分别说明连接失败和慢响应的观测办法；不要用统一的大超时掩盖应用瓶颈。
6. 对修改前后分别执行同一请求矩阵，校验状态码、响应类型、重定向地址和关键业务内容。补充同机其他站点的回归检查及配置恢复步骤。

输出：请求路径对照表、按证据排序的问题、必要配置差异、验证请求与预期响应。没有实际请求证据时，只提供诊断假设和下一步取证方法。

依据与范围
- [阿里云 · Access OSS through an ECS Nginx reverse proxy](https://www.alibabacloud.com/help/en/oss/user-guide/access-oss-through-ecs-reverse-proxy)
核验日期：2026-09-08。依据公开资料改写的执行模板；原文限定 OSS 代理场景；普通业务反向代理的检查步骤为本站扩展。

请根据现有环境完成 Nginx HTTPS 部署审查，输出可执行的变更方案；已授权实际部署时，再按方案实施并记录结果。

输入：域名 域名；操作系统与 Nginx 版本 运行环境；现有主配置与站点配置 配置资料；证书文件所在位置 证书路径；上游服务地址 服务地址；允许修改的站点 变更范围。

1. 确认正在运行的 Nginx 可执行文件、实际加载的配置入口、include 关系与重载方式，核对是否支持 SSL。盘点同机其他域名和证书目录，沿用现有管理结构。
2. 读取证书的域名范围、有效期、签发链与公钥信息，验证证书与私钥匹配。只报告匹配结论和到期时间，不在输出中展示私钥正文；CSR 不作为服务端证书配置。
3. 按本次授权目标域名配置 server_name，再确认这些域名被证书覆盖，不因多域名或通配符证书扩大站点范围。区分 HTTP 跳转和 HTTPS 代理，保留路径与查询参数；检查是否已有 CDN 或负载均衡终止 TLS，避免重复跳转。
4. 根据 Nginx、OpenSSL 和客户端兼容范围确定 TLS 配置，不原样复制旧教程。核对登录回调、Cookie、上传大小及服务原有路径，业务端口按网络拓扑限制在回环或可信内网。
5. 保存本次涉及配置的恢复副本，使用实际运行实例检测完整配置。仅在检测通过后重载，确认旧站点、目标站点及进程状态；失败时恢复本次修改文件。
6. 从外部域名验证证书链、域名匹配、HTTP 跳转、首页、登录及关键接口。证书续期要说明责任人、替换位置和复验方法，不能把一次部署称为自动续期。

输出：环境核对表、最小配置差异、证书检查结果、逐项验收证据、恢复步骤。无法获取的环境信息列为待核实，不编造已通过结果。

依据与范围
- [腾讯云 · Nginx 服务器 SSL 证书安装部署（Linux）](https://cloud.tencent.com/document/product/400/35244)
核验日期：2026-09-08。依据公开资料改写的执行模板；示例环境为 CentOS 7 和 Nginx 1.18.0；不代表当前版本选型建议。