Nginx代理超时若由MTU不一致引发，本质是底层TCP分片失败导致连接卡顿或重传，表现为小请求正常、大响应卡在“reading response”、Wireshark显示大量TCP重传或“TCP segment of a reassembled PDU”；需通过ping探测路径MTU（成功最大值+28），对比本地MTU，若本地更大则存在风险，可临时调低出口MTU或用iptables --clamp-mss-to-pmtu强制MSS协商，并配合ssl_buffer_size 1400和tcp_nodelay优化。
Nginx 代理超时若由 MTU 不一致引发，本质不是 Nginx 配置问题，而是底层 TCP 分片失败导致连接卡顿或重传，最终触发 proxy_read_timeout 或 proxy_send_timeout 超时。这类问题特征明显：小请求正常、大响应（如文件下载、长 JSON）频繁卡在“reading response”阶段，Wireshark 可见大量 TCP 重传或 “TCP segment of a reassembled PDU” 提示。
确认路径 MTU 是否受限
先验证是否真为 MTU 问题，避免盲目调参：
- 在运行 Nginx 的服务器上执行路径 MTU 探测：
- Linux：
ping -M do -s 1472 <上游服务IP>（从 1472 开始递减，找到最大不报 “Packet needs to be fragmented but DF set” 的值） - Windows：
ping -f -l 1472 <上游服务IP>
- Linux：
- 计算路径 MTU = 最大成功 size + 28（ICMP 头 8 字节 + IP 头 20 字节）
- 查看本机网卡 MTU：
ip link show dev eth0 | grep mtu（替换为实际接口名） - 若本机 MTU > 路径 MTU（例如本地设 1500，实测路径仅 1400），即存在分片风险
临时修复：降低客户端出口 MTU
适用于快速验证和短期缓解：
- Linux（临时）：
sudo ip link set dev eth0 mtu 1400 - Linux（持久）：写入
/etc/network/interfaces（Debian）或/etc/sysconfig/network-scripts/ifcfg-eth0（RHEL） - Windows：
netsh interface ipv4 set subinterface "以太网" mtu=1400 store=persistent - macOS：
sudo ifconfig en0 mtu 1400
长期稳定：用 iptables 自动适配 MSS（推荐）
不改动 MTU，避免影响其他流量吞吐，让 TCP 握手阶段就协商合适 MSS：
- 执行命令（需 root 权限）：
sudo iptables -t mangle -A OUTPUT -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
- 此规则作用于所有出向 SYN 包，自动根据路径 MTU 推导 MSS（MSS = 路径 MTU − 40），彻底规避 IP 分片丢包
- 重启后需持久化（如保存至
/etc/iptables/rules.v4）
协同检查 Nginx 与 HTTPS 缓冲设置
MTU 问题常在 HTTPS 场景下加剧（TLS record + TCP header 易超限）：
- 在
http{}块中设置：ssl_buffer_size 1400; # 避免 TLS record 过大触发分片 tcp_nodelay on; # 禁用 Nagle，小包及时发出
- 若使用反向代理，确保
proxy_buffers不过度分配（如proxy_buffers 8 4k），避免缓冲区等待超大响应块
不复杂但容易忽略
