nginx的error_log不记录标准http状态码，仅记录自身运行错误；497可被warn级日志记录并用error_page重定向，499仅为info级连接中断标记且不可拦截，其他非标码需按触发机制分类处理。
Nginx 的 error_log 本身不记录 HTTP 状态码（包括非标准码），它只记录 Nginx 自身运行时的底层错误、警告和调试信息。所谓“非标准错误码”如 497、499，其日志表现和处理逻辑各不相同，不能一概而论为“error_log 记录了这些状态码”，而应区分它们的来源与可干预性。
497（HTTP 请求发到 HTTPS 端口）可被 error_log 记录并主动干预
497 是 Nginx 内部生成的非标准状态码，用于标识明文 HTTP 请求误入 HTTPS 监听端口。它会触发 error_log 记录（级别通常为 warn），例如：
这类日志明确可读，且可通过 error_page 拦截并重定向：
- 在 HTTPS
server块中添加：error_page 497 =301 https://$host$request_uri; - 若 HTTPS 使用非标端口（如 8443），需显式带上端口：
error_page 497 =301 https://$host:$server_port$request_uri; - 该配置仅影响 497，不影响其他请求；重定向类型用
=301或=307显式指定
499（客户端主动断连）不会被 error_page 拦截，error_log 仅作标记
499 不是 Nginx 主动返回的状态码，而是日志中对“连接被客户端关闭”的事后标记。Nginx 未发出响应即连接中断，因此 error_page 对其完全无效。
error_log 中可能看到类似条目（级别 info）：
这不是配置错误，而是用户侧行为（如页面刷新、网络切换、APP 后台终止）。应对重点不在日志策略，而在：
- 调优超时参数：适当增大
client_header_timeout、send_timeout - 前端优化：防重复提交、加载状态反馈、取消挂起请求（如 AbortController）
- 监控识别：大量 499 往往伴随高跳出率或弱网指标，应结合前端埋点分析
其他非标码（如 444、495、496）需按机制分类对待
Nginx 支持部分内部非标码，但是否记入 error_log 取决于触发环节：
-
444（直接关闭连接）：常用于拒绝恶意请求，不产生响应，error_log一般不额外记录，除非配合log_not_found off或自定义日志格式显式捕获 -
495/496（SSL 证书相关失败）：由 SSL 握手阶段触发，error_log会记录详细原因（如SSL_do_handshake() failed），级别多为info或warn，可结合ssl_verify_client配置调整行为 - 所有非标码都不支持
error_page重写响应体（如返回 HTML 页面），仅 497 和少数 SSL 相关码支持跳转或拦截
统一建议：用日志级别 + 上下文变量提升诊断效率
无论哪类非标码，error_log 的核心价值在于定位问题源头。推荐实践：
- 生产环境将
error_log级别设为warn，避免淹没关键信号；调试时临时切至info查看 497/499 触发频次 - 在
http或server块中启用自定义log_format，加入$status和$request_length等字段，辅助关联 access_log 与 error_log 行为 - 对高频 497，检查是否遗漏 HSTS 或强制跳转配置；对突增 499，优先排查 CDN 缓存策略或移动端弱网适配
