Nginx中proxy_pass本身不处理异常，兜底依赖proxy_*指令组合：需分层配置超时（connect/send/read）、谨慎启用proxy_next_upstream重试（限error/timeout/502-504，配tries与timeout）、通过upstream的max_fails/fail_timeout+backup实现被动健康检查，并用error_page返回友好降级响应。
proxy_pass 本身不处理异常，真正起兜底作用的是它配套的 proxy_* 指令组合。关键不是“怎么写 proxy_pass”，而是怎么用好超时、重试、健康检查和错误响应这四类机制。
设置合理的超时时间，避免级联等待
默认超时太短（60 秒）会误杀慢接口，太长（如 300 秒）又拖垮连接池。应按后端实际响应特征分层配置：
- proxy_connect_timeout：建议设为 5–10 秒，仅控制与后端建连耗时，过长会卡住 worker 进程
- proxy_send_timeout：对应请求体发送，一般 30 秒足够；若上传大文件，可单独在 location 中提升
- proxy_read_timeout：最需谨慎——Spring Boot 默认 Tomcat 超时是 20 秒，这里建议设为 25–30 秒，比后端多留 5 秒缓冲
用 proxy_next_upstream 控制重试逻辑
盲目开启重试反而放大故障。只应在明确可恢复的场景下启用：
WeChat macOS Proxy
下载
macOS 微信消息自动化工具。通过 GUI 自动化实现：发送消息给指定联系人、读取聊天内容、监控新消息。适用于需要自动化微信操作的场景，如定时发送、批量回复、消息备份等。依赖 peekaboo 进行屏幕截图和 UI 交互。仅支持 macOS。开源地址：https://github.com/chairmanmia...
- 重试条件选 error timeout http_502 http_503 http_504，不加
invalid_header（说明 upstream 返回非法响应，重试无意义） - 必须配合 proxy_next_upstream_tries（建议最多 2 次）和 proxy_next_upstream_timeout（建议 ≤ proxy_read_timeout）
- 若后端是单点，禁用重试；只有在 upstream 有多个 server 且部署了主动健康检查时，重试才安全
给 upstream 加主动健康检查（开源版需手动模拟）
开源 Nginx 不支持 health_check 指令，但可通过以下方式实现基础兜底：
- 在 upstream 块中用 max_fails=2 fail_timeout=30s 标记连续失败节点
- 搭配 backup 参数定义备用服务器，例如：
server 192.168.1.10:8080 max_fails=2 fail_timeout=30s;和server 192.168.1.11:8080 backup; - 对关键服务，可加一个轻量级探活 endpoint（如 /health），用 cron + curl 定期调用，失败时自动 reload 配置或触发告警
返回友好错误页或降级响应
当所有 upstream 都不可用时，别让客户端卡死或看到空白：
- 用 error_page 502 503 504 /50x.html 指向静态兜底页，该页可带“服务暂不可用”提示和刷新按钮
- 更进一步，用 error_page 502 =200 /fallback.json 直接返回预置 JSON 降级数据（需提前准备 fallback.json 文件）
- 注意：/fallback.json 要放在 root 指定的目录下，并确保 location ~ \.json$ {} 中未做额外 proxy_pass，否则会循环代理
