2.3 HTTP块核心指令速查
2.3 HTTP块核心指令速查
本节摘要：HTTP 块是 nginx.conf 里最密集的一层。本节按"影响哪条线上指标"把高频指令分成连接处理、文件发送、日志、缓冲四组，每组给出生产取值与理由，可当速查表用。
连接处理组：决定客户端侧行为
http { keepalive_timeout 30s; # 空闲长连接保留时长 keepalive_requests 1000; # 单条连接最大请求数 client_header_timeout 10s; # 读请求头超时 client_body_timeout 10s; # 读请求体超时 send_timeout 15s; # 写响应超时 client_max_body_size 20m; # 请求体上限，超限回 413 }
这些超时的共同目标是防慢客户端拖垮连接池。默认值往往偏宽松，公网服务建议全部显式收紧。client_max_body_size 默认只有 1m，上传业务没调它必然收到一片 413 报障。
文件发送组：静态内容的快车道
sendfile on; # 内核态直传文件，不经过用户态拷贝 tcp_nopush on; # 配合 sendfile，攒满包头再发 tcp_nodelay on; # 小包立即发，keepalive 下降低延迟 open_file_cache max=10000 inactive=60s; open_file_cache_valid 60s;
open_file_cache 缓存的是文件元数据（inode、大小），省掉每次请求的 stat 系统调用。静态文件量大、访问集中的站点收益明显。
日志组：排障的眼睛
log_format main '$remote_addr - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent" ' 'rt=$request_time urt=$upstream_response_time'; access_log /var/log/nginx/access.log main buffer=64k flush=5s;
两个线上必备字段：$request_time 是 Nginx 全程耗时，$upstream_response_time 是后端耗时——两者相减就能判断慢在传输还是慢在后端，第六章的 502 复盘全靠它们。buffer 加 flush 让日志写入合并落盘，高流量下减少 IO 抖动。
⚠️ access_log 的 buffer 会让日志延迟最多 flush 秒数出现，故障现场抓日志时别以为"日志停了"。
缓冲组：代理场景的减震器
proxy_buffer_size 16k; # 读后端响应头的缓冲 proxy_buffers 8 32k; # 读后端响应体的缓冲 proxy_busy_buffers_size 64k; # 忙时缓冲上限 proxy_max_temp_file_size 0; # 禁止落盘，防打满磁盘
后端一次吐出大响应时，缓冲先接住，客户端慢慢取。默认值偏小，遇到 "upstream sent too big header" 报错就是 proxy_buffer_size 不够，先加倍再细调。
图：一个请求经过的缓冲链路
超时组的联动设计
四类超时不是孤立的，它们构成一条从客户端到后端的完整超时链。设计原则：入口层的总耗时要略小于客户端与上游各自超时之和的较小者，让"报超时"的责任落在真正慢的那一层。一个实测过的参考结构：
客户端 SDK 超时 5s └ Nginx send_timeout 15s（对客户端写） └ proxy_read_timeout 30s（等后端）→ 慢接口单独 location 放宽到 120s └ 后端应用自身超时 28s（必须小于 proxy_read_timeout）
关键点是最后一行：后端自身超时若大于代理层超时，后端还在傻等外部依赖时，Nginx 已经先回 504，后端的计算全成了无用功，还占着连接。全链路超时从外向内递减，每层留一两秒余量，这是避免"超时雪崩"的配置形态。
client_max_body_size 的排错现场
上传接口报 413 是新手值班最常遇到的问题之一，处理顺序固定三步。第一步确认请求体大小与配置值，用 curl 复现：
# 生成 25MB 测试文件并上传，观察状态码 dd if=/dev/zero of=/tmp/test.bin bs=1M count=25 curl -v -F "file=@/tmp/test.bin" https://shop.example.com/upload # 返回 413 Payload Too Large 即命中
第二步检查生效层级——client_max_body_size 可写在 http、server、location 三级，实际生效的是离请求最近的那个，location 里残留的历史小值经常覆盖掉 server 层的新值。第三步别忘了代理链：Nginx 前面若还有一层负载均衡或 CDN，每层的请求体上限都要过一遍，任何一层卡住都表现为 413。
速查表的用法补充一句：HTTP 块指令的正确位置感来自"它在请求生命周期的哪一步生效"。超时组在连接建立前后各管一段，文件发送组只在响应体是本地文件时介入，缓冲组仅在代理场景存在，日志组贯穿始终。带着生命周期视图读配置，遇到"指令不生效"的问题时，先问它所属的阶段有没有被执行到——比如 proxy_buffer_size 对 Nginx 直出的静态请求毫无作用，因为它根本不经过代理阶段。这张心理时间轴比背指令清单更耐用。
本节要点回顾
- 超时组全显式收紧，防慢客户端占用连接；上传业务必查 client_max_body_size；
- sendfile 加 nopush 是静态内容的标配组合；
- 日志加 request_time 与 upstream_response_time，排障价值极高；
- 代理缓冲默认偏小，遇到 header 报错先加倍 proxy_buffer_size。