proxy_pass 本身不直接导致丢包，真正根因是底层连接调度、缓冲机制与超时协同失效；需调优内核参数、Nginx listen backlog、worker 文件描述符、事件模型、upstream 复用、超时对齐、缓冲配置及代理链路精简。
proxy_pass 本身不直接导致丢包，真正引发丢包的是它所依赖的底层连接调度、缓冲机制和超时协同失效。大规模并发下出现“proxy_pass 丢包”，通常表现为客户端收到不完整响应、连接重置（RST）、502/504 或响应延迟后中断——这些是表象，根因在链路各环节未对齐。
确保连接能被系统和 Nginx 及时收下
大量请求卡在 TCP 接入阶段，就会触发 SYN 丢包或 accept 队列溢出，后续根本到不了 proxy_pass 环节：
- 调高内核参数：net.core.somaxconn 和 net.ipv4.tcp_max_syn_backlog 均设为 65535，避免默认值（常为 128）成为瓶颈
- Nginx listen 必须显式声明 backlog：listen 80 backlog=65535;，否则即使内核调高也无效
- 每个 worker 进程文件描述符要够用：worker_rlimit_nofile 1048576;，并确保系统 ulimit -n ≥ 同值
- 启用高效事件模型：use epoll; + multi_accept on; + accept_mutex off;，让多个 worker 并行处理新连接
避免 proxy_pass 后连接堆积与泄漏
后端响应慢或超时设置错位，会让连接滞留在 Nginx 的 upstream 队列中，最终耗尽资源，表现为“丢包”或连接拒绝：
WeChat macOS Proxy
下载
macOS 微信消息自动化工具。通过 GUI 自动化实现：发送消息给指定联系人、读取聊天内容、监控新消息。适用于需要自动化微信操作的场景，如定时发送、批量回复、消息备份等。依赖 peekaboo 进行屏幕截图和 UI 交互。仅支持 macOS。开源地址：https://github.com/chairmanmia...
- upstream 中开启连接复用：keepalive 200;（推荐 100–300），配合 keepalive_requests 1000;
- 透传 HTTP/1.1 长连接：proxy_http_version 1.1; + proxy_set_header Connection "";
- 超时必须对齐：proxy_read_timeout 应略小于后端 keepalive timeout（如后端设 60s，Nginx 设 55s），防止连接挂死不释放
- 关闭非必要 header 缓冲：client_header_buffer_size 1k; + large_client_header_buffers 2 2k;，防恶意大 header 耗尽内存
优化大响应转发路径，减少缓冲区溢出与落盘
proxy_pass 转发大响应（如文件下载、JSON 流）时，默认缓冲易触发临时文件写入，I/O 延迟放大后表现为丢包或中断：
- 增大响应缓冲：proxy_buffer_size 128k;（头） + proxy_buffers 8 128k;（体）
- 控制忙时缓冲上限：proxy_busy_buffers_size 256k;（建议为单 buffer 两倍）
- 禁用磁盘缓存：proxy_max_temp_file_size 0;，强制全部走内存（需确保内存充足）
- 延长读取等待：proxy_read_timeout 120;，匹配大响应实际传输时间
- 流式场景可关缓冲：proxy_buffering off;，适用于视频分片、日志流等实时转发
精简代理链路，降低中间处理开销
每多一层 header 处理、重写或校验，都在增加 CPU 和延迟风险，高并发下易成瓶颈：
- 只保留必需 header：proxy_set_header Host $host; + X-Real-IP $remote_addr;，移除非必要项（如重复的 X-Forwarded-For）
- 若后端不返回重定向，关闭重写：proxy_redirect off;
- 静态资源或直出流，关闭 gzip：gzip off;，避免压缩反成负担
- 启用零拷贝加速：sendfile on; + tcp_nopush on;，尤其利于大文件传输
