原因很简单：对普通网站，证书过期是"用户看到一个可怕的警告，但能点继续"；对 API 网关，证书过期是所有客户端硬失败的全站中断。Python 的 httpx、requests、OpenAI SDK 全都会直接抛 SSLError，没有"点继续"这个选项。而且报错文本是 certificate verify failed，第一眼看着像客户端环境问题，会把人引到完全错误的方向排查。

一张手动证书的真实时间线

我手上一台机器用的是 nginx 加商业 DV 证书（TrustAsia 签发），实测有效期：

notBefore = Jun 18 08:00:00 2026 GMT
notAfter  = Sep 16 07:59:59 2026 GMT

正好 90 天。查证书那天是 9 月 3 日，距到期 13 天。

这台机器上跑着 API 服务和一个静态站，证书是手工申请、手工安装的。它现在没坏，问题是它的存续完全依赖"有人记得"——记得到期日、记得去续、记得装上去、记得 reload。这三个月里只要有一次没记住，就是一次全站中断。

顺带说一个正在发生的趋势，它会让手动方案越来越站不住：证书有效期正在被行业强制缩短。 按 CA/Browser Forum 已通过的决议，TLS 证书最长有效期会分阶段从原来的一年多压到 200 天、100 天，最终到 47 天量级。手动续期在一年一次的年代还算可行，压到两个月一次就必然出事——这不是效率问题，是可靠性问题。

两者的实际差异

看这张表要抓重点：除了第一行和最后一行，其余差异对一个 API 网关都不构成决策依据。 反代能力两边都够，性能差异在 LLM 场景里被上游生成耗时完全淹没——你的瓶颈是模型在想，不是代理在转发。

Caddy 的代价也要说清，别只看好处：

• 需要出网访问 ACME 目录。 内网隔离环境、或出网被严格管控的机器上，自动签发根本走不通，这时 Caddy 的核心优势直接消失。
• on_demand_tls 是个陷阱。 配错了会给任意 Host 头签发证书，等于把签发配额敞开给别人刷。要用就必须配 ask 端点做白名单校验。
• 复杂路由场景 nginx 更稳。 如果你已经有一大堆 nginx 的 location 规则和正则，重写成 Caddyfile 的风险可能高于收益。

不换 nginx 的话，certbot 要配对

大多数人的现实是 nginx 配置已经很复杂、不想动。那就把证书自动化补上，同样能解决问题：

# 首次签发。--deploy-hook 是关键，否则证书换了但 nginx 还在用内存里的旧的
certbot certonly \
  --webroot -w /var/www/acme \
  -d ambertu.com -d www.ambertu.com \
  --deploy-hook "systemctl reload nginx"

# 确认自动续期的定时器真的在跑 —— 这一步很多人跳过
systemctl list-timers | grep certbot

# 演练一次，别等到真到期才发现签发链路是坏的
certbot renew --dry-run

三个容易漏的点：

• --deploy-hook 不能省。 证书文件换了，但 nginx 不会自己重新读——不 reload 就等于没续。
• systemctl list-timers 必须确认。 certbot 的自动续期靠 systemd timer（或 cron），装了 certbot 不代表定时器启用了。
• --dry-run 要定期跑。 签发链路可能因为 DNS 变更、防火墙调整、challenge 路径被占而悄悄失效，--dry-run 是唯一能提前发现的手段。

一个共享域名下的真实坑：ACME 验证被吞掉

这个坑值得单独讲，因为它只在"一个域名下住着多个应用"时出现，而这种架构相当常见。

HTTP-01 验证要求 http://your-domain/.well-known/acme-challenge/<token> 能被访问到。问题是：这个路径会命中哪个 location？

正确的配法：

# 80 端口的 server 块里 —— 顺序很重要
server {
    listen 80;
    server_name ambertu.com www.ambertu.com;

    # ACME 验证必须放在 301 之前，否则请求会被跳转走
    location /.well-known/acme-challenge/ {
        root /var/www/acme;
    }

    location / {
        return 301 https://$host$request_uri;
    }
}

顺序是关键。 如果 80 端口的 server 块里只有一句 return 301 https://...，那么 ACME 的验证请求会被 301 走。Let’s Encrypt 会跟随跳转到 443，所以这种情况有时也能成——但如果 443 上的 location / 又用 try_files ... =404 兜底，请求最终还是 404。加一个显式的前缀 location 才是确定的做法，不依赖跳转链路碰巧走对。

再说一遍那个连带的坑：验证目录要放在任何应用的部署产物之外。 如果你把 webroot 指向静态站的根目录，而部署脚本用的是 rsync --delete 式的镜像同步，.well-known 会在下一次发版时被删掉——证书在三个月后续期失败，而当时没有人会想起两个月前改过部署脚本。

混合方案

如果 nginx 配置太复杂不想重写，但又想要自动证书，可以让 Caddy 只做 TLS 终止：

外网 → Caddy :443（自动证书） → nginx :8080（全部现有路由逻辑） → 各应用

Caddyfile 简单到几行：

ambertu.com, www.ambertu.com {
    reverse_proxy 127.0.0.1:8080 {
        flush_interval -1          # 保住 SSE 流式
        header_up X-Real-IP {remote_host}
    }
}

代价是多一跳（本机回环，延迟可忽略），以及 nginx 那边要改成监听 8080 且信任来自本机的 X-Real-IP——这一步别搞错，否则所有客户端 IP 都会变成 127.0.0.1，按 IP 的限流会一起误伤。

无论用哪个：把到期日变成告警

这是这篇文章最该带走的一条。再好的自动化也可能静默失效，所以到期监控是独立于方案选择的必需品：

#!/bin/sh
# /usr/local/bin/cert-expiry-check.sh
DOMAIN="${1:-ambertu.com}"
THRESHOLD=20

END=$(echo | openssl s_client -connect "$DOMAIN:443" -servername "$DOMAIN" 2>/dev/null \
      | openssl x509 -noout -enddate | cut -d= -f2)
[ -z "$END" ] && { echo "无法获取证书：$DOMAIN"; exit 2; }

DAYS=$(( ( $(date -d "$END" +%s) - $(date +%s) ) / 86400 ))
echo "$DOMAIN 证书剩余 $DAYS 天（到期 $END）"
[ "$DAYS" -lt "$THRESHOLD" ] && { echo "低于 $THRESHOLD 天，需要处理"; exit 1; }
exit 0

两点设计考虑：

• 从外部探测，而不是读本地证书文件。 读文件只能证明"磁盘上那份还有效"，探端口才能证明"nginx 实际吐出去的那份还有效"。两者不一致正是"续了但忘了 reload"这个经典故障的样子。
• 阈值设 20 天而不是 3 天。 要留出的不是"续期需要的时间"，而是"发现问题、排查、找人、处理"的时间。

配个定时任务每天跑一次，非零退出就告警。这十几行东西能挡住的，是那种"周末证书过期、周一早上所有客户端集体报 SSL 错误"的事故。

相关阅读

• 大模型 API 中转的超时与重试：一次 504 可能让你双倍计费 —— 另一类会让全部请求一起失败的配置问题
• 反代把大模型 API 的 SSE 流式响应缓冲了：五个缓冲点与三层排查法 —— 换成 Caddy 后 SSE 的行为差异
• API 中转站的限流为什么不能信 X-Forwarded-For —— 混合方案里 X-Real-IP 那一跳为什么必须配对

客户端最终只拿到一个响应，你的账单上是两笔。更麻烦的是这件事在监控里几乎看不出来：错误率只涨了一点，成本却在悄悄翻倍。

先纠正一个常见的误解.

网上很多文章会告诉你 nginx 的 proxy_next_upstream 会把超时请求转给下一个上游、导致重复计费。这个说法对 LLM API 来说是不准确的，值得先说清楚，否则你会去改一个本来没问题的配置。

proxy_next_upstream 的默认值确实是 error timeout，但 nginx 从 1.9.13 起有一条额外规则：

非幂等方法（POST、LOCK、PATCH）的请求，一旦已经发送给上游，就不会再转给下一台服务器——除非你显式加上 non_idempotent 选项。

LLM 的 chat completions 走的是 POST，所以 nginx 默认行为是安全的。真正的重复计费来源有两个，都不是 nginx 的默认配置：

1. 有人手工加了 non_idempotent——一些"提升可用性"的高可用教程会教这个，在普通 Web 服务上无害，在按 token 计费的接口上是直接烧钱。
2. 客户端 SDK 自己在重试——这是绝大多数情况的元凶。OpenAI 官方 Python SDK 的 max_retries 默认是 2，重试触发条件包含连接错误、408、409、429 和所有 5xx。nginx 吐的 504 正好落在 5xx 里。

双倍计费是怎么发生的

流式请求几乎不会撞上这个问题

这是很多人不知道的一点，也是"默认就该用流式"的一个纯运维理由。proxy_read_timeout 的官方定义是：

该超时只作用于两次连续读操作之间，而不是整个响应的传输时长。

所以：

• 非流式请求：从发出到收到完整 JSON，中间是一个长长的空隙。生成花 75 秒，就是一个 75 秒的读间隔 → 撞上 60 秒超时。
• 流式请求：token 一个接一个到达，每两次读之间只隔几百毫秒 → 无论总时长多久都不会触发超时。

正确的超时分层

关键是区分"连不上"和"生成慢"：前者应该快速失败，后者必须耐心等。用一个统一的大数字把三个超时都拉长，是把两种完全不同的故障混在一起处理。

location /v1/ {
    proxy_pass http://upstream_pool;

    # 连不上 → 快速失败。请求还没发出去，此时重试是安全的
    proxy_connect_timeout  5s;

    # 发送请求体 → 大 prompt 也就几百 KB，给足但不必夸张
    proxy_send_timeout     60s;

    # 读响应 → 生成慢是正常的，不是故障。这里必须放宽
    proxy_read_timeout     600s;

    # LLM 是非幂等的：绝不要开 non_idempotent
    # 保守起见连 timeout 重试也去掉，只保留连接阶段的重试
    proxy_next_upstream    error;
    proxy_next_upstream_tries 2;
    proxy_next_upstream_timeout 10s;

    # 流式必须配套，否则响应被攒起来又变回一个长读间隔
    proxy_buffering        off;
    gzip                   off;
    proxy_http_version     1.1;
    proxy_set_header       Connection "";
}

客户端侧要做的事

服务端配对了，客户端如果还在盲目重试，问题只是变少而不是消失。

from openai import OpenAI

client = OpenAI(
    base_url="https://your-gateway/v1",
    api_key="...",
    max_retries=0,   # 默认是 2，对按 token 计费的接口必须显式关掉
    timeout=600.0,   # 客户端超时也要放宽，否则轮到它先放弃
)

关掉自动重试之后，重试逻辑要自己写，并且只在明确安全的错误上重试：

更彻底的办法：在中转层做请求去重

如果你控制中转层（自建 new-api 之类就是这种情况），可以在网关上加一层短窗口去重，把重复计费在源头掐掉：

思路是给每个请求算一个指纹——模型名 + 消息体 + 关键参数的哈希——配上客户端标识，在 Redis 里存一个几十秒的短 key。窗口内出现相同指纹时，不再打上游，直接返回上一次的结果或一个明确的"重复请求"错误。

这个做法的取舍要讲清楚：

• 好处：无论客户端怎么重试，上游只被打一次，账单可控。
• 代价：LLM 本身是有随机性的（temperature > 0 时同样输入本该有不同输出），去重会让窗口内的重复请求拿到相同结果。对聊天场景通常无害，对"故意重新生成一次"的功能就是 bug。
• 所以：窗口要短（几十秒量级），并且给客户端一个显式绕过的办法（比如一个请求头或一个随机 nonce 参数）。

怎么发现自己已经在被双倍计费

从日志里找证据，不用等账单。特征是：同一客户端在很短时间内发出内容完全相同的请求，且其中至少一个返回了 504。

# 找 504：如果这个数不是 0，就值得往下查
awk '$9==504 {print $1, $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

# 找 504 之后紧跟着重试的模式：同 IP、同路径、几秒内连续多次
awk '$9==504 || $9==200 {print $1, $4, $9, $7}' /var/log/nginx/access.log \
  | grep '/v1/chat/completions' | tail -50

更可靠的信号是把上游用量与自己记录的成功响应数对账：如果上游统计的请求数明显高于你返回给客户端的成功数，差额基本就是被白烧掉的重试。

相关阅读

• 反代把大模型 API 的 SSE 流式响应缓冲了：五个缓冲点与三层排查法 —— 本文说流式不容易超时，前提是流式真的没被缓冲掉
• Caddy 还是 nginx 给 API 中转做反代：证书自动化是决定性差异 —— 另一类会让全部请求一起失败的运维故障
• new-api 部署选型：2G 小内存机器上裸二进制比 Docker 省多少 —— 超时配置所在的那层反代怎么部署
• 给 API 中转站选数据库：SQLite / MySQL / PostgreSQL 在小机器上的取舍 —— 本文说的"拿用量日志对账"，那张表本身也会变成问题

根本原因一句话：X-Forwarded-For 是追加语义，X-Real-IP 是覆写语义。 前者保留客户端自带的值，后者丢弃。这个区别决定了哪个可信。

追加与覆写的区别

nginx 里这两行长得很像，行为完全不同：

# 追加：把 $remote_addr 拼在客户端已有的 XFF 后面
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

# 覆写：无条件用 $remote_addr 替换，客户端塞的值被丢掉
proxy_set_header X-Real-IP $remote_addr;

$proxy_add_x_forwarded_for 这个变量的定义就是"客户端请求里的 XFF 值 + , + $remote_addr"。所以攻击者只要在请求里带上 X-Forwarded-For: 1.2.3.4，上游收到的就是：

X-Forwarded-For: 1.2.3.4, 203.0.113.77
                 ↑伪造      ↑真实（nginx 追加的）

而绝大多数框架和教程都教你取 XFF 的第一个值当客户端 IP——理由听起来也很合理：“最左边是最原始的客户端”。这个说法在没有攻击者的世界里成立，在真实互联网上是漏洞。

前提：反代必须是唯一入口

X-Real-IP 可信有一个隐含前提——所有流量都必须经过反代。如果后端端口自己也在公网上听着，攻击者直连后端，想塞什么头就塞什么头，覆写逻辑根本不会执行。

这个疏漏比想象中普遍。写这篇文章的时候我顺手扫了自己的机器，发现两个问题：一个 Go 服务监听了 0.0.0.0 而不是 127.0.0.1，公网直接可达；更糟的是数据库端口也在安全组里开着，从外网能直接拿到 MariaDB 的协议握手包和版本号。两个都是历史遗留，跑了很久没人注意——因为从正常入口访问一切都是对的，问题只在你主动去扫端口时才会现形。

自查两条命令，五秒钟的事：

# 本机看监听地址：凡是 0.0.0.0 或 * 开头的都要问一句"为什么"
ss -tlnp

# 从外网验证（换成你的公网 IP 和端口），能连上就是有问题
curl -sv -m 5 http://YOUR_PUBLIC_IP:8080/ 2>&1 | head -5

第二条必须从机器外面跑。在机器上自己 curl 自己永远是通的，测不出安全组的实际策略。

修法按优先级：

1. 应用只监听本地——大多数框架都能配，Go 里就是 http.ListenAndServe("127.0.0.1:8081", h) 而不是 ":8081"
2. 安全组只开 22 / 80 / 443——这是最后一道闸，也是最不容易被应用改动破坏的一道
3. 数据库一律不开公网——需要远程访问就走 SSH 隧道：ssh -L 3306:127.0.0.1:3306 user@host

正确的限流写法

nginx 层限流：天然安全

如果限流在 nginx 做，用 $binary_remote_addr 就好——它取的是 TCP 连接的对端地址，不是任何请求头，客户端无法伪造：

# http 块
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

location /v1/ {
    limit_req zone=api burst=20 nodelay;
    limit_req_status 429;
    proxy_pass http://127.0.0.1:3000/v1/;
}

用 $binary_remote_addr 而不是 $remote_addr 是内存考虑：前者是 4 字节（IPv4），后者是字符串，在 10m 的 zone 里能存的条目数差好几倍。

应用层限流：只信覆写过的头

如果限流逻辑在应用里（比如要按用户 + IP 组合计数），那就只认 X-Real-IP：

// ✓ 只信反代覆写的头，且兜底用 TCP 对端地址
func clientIP(r *http.Request) string {
    if ip := r.Header.Get("X-Real-IP"); ip != "" {
        return ip
    }
    host, _, _ := net.SplitHostPort(r.RemoteAddr)
    return host
}

绝对不要写成这样：

// ❌ 取 XFF 第一个值 —— 完全由客户端控制
func clientIP(r *http.Request) string {
    if xff := r.Header.Get("X-Forwarded-For"); xff != "" {
        return strings.Split(xff, ",")[0]  // 攻击者说什么就是什么
    }
    ...
}

我自己的 pet 服务在这一处踩过，最后在 nginx 配置里留了行注释提醒自己：X-Real-IP 不能少，注册限流只认这个头，因为 XFF 客户端能自己塞。 这类结论写在配置文件旁边比写在文档里有用得多——改配置的人一定会看到它。

前面还有 CDN 怎么办

如果套了 CDN，$remote_addr 是 CDN 节点的 IP，直接覆写 X-Real-IP 会把全站流量都算成同几个 CDN 节点，限流立刻误伤所有人。这时候要用 nginx 的 realip 模块，而不是自己解析 XFF：

# 声明哪些来源是可信代理（填 CDN 的回源网段，各家文档都有公布）
set_real_ip_from 203.0.113.0/24;
set_real_ip_from 198.51.100.0/24;

real_ip_header    X-Forwarded-For;
real_ip_recursive on;          # 这一行是安全的关键

配好之后 $remote_addr 会被改写成真实客户端 IP，前面所有基于 $remote_addr 的限流、X-Real-IP 覆写都自动正确，不用改一行业务代码。

real_ip_recursive on 为什么是安全的关键，值得画一下：

两个配置陷阱：

• real_ip_recursive off（默认值）在有 CDN 时是错的。 关闭递归时 nginx 只取 XFF 的最后一个地址，那就是 CDN 节点自己，等于没解析。
• set_real_ip_from 千万别填 0.0.0.0/0。 把所有来源都标为可信，递归就会一路扫到最左边——正好扫到攻击者伪造的那个值，比不配还糟。见过有人为了"省事"这么写。

一份自查清单

相关阅读

• 反代把大模型 API 的 SSE 流式响应缓冲了：五个缓冲点与三层排查法 —— 同一份 nginx 配置里的另一个坑
• new-api 部署选型：2G 小内存机器上裸二进制比 Docker 省多少 —— 后端监听 127.0.0.1 在两种部署形态下怎么配

这个问题九成不在应用代码里，而在 nginx 的 proxy_buffering 默认是开启的。但真正麻烦的地方是：请求路径上会缓冲的地方不止 nginx 一个，实际有五个，而且其中一个是你用来排查的 curl 自己。如果不知道这一点，你会在错误的层上改半天配置。

先分清 SSE 和 WebSocket

这是配置写错的根源。大模型 API 的流式输出用的是 SSE（Server-Sent Events）：一个普通的 HTTP 响应，Content-Type: text/event-stream，靠 chunked 编码持续往下写。它不涉及协议升级。

而网上大量"流式接口反代配置"教程给的是 WebSocket 的写法：

# ❌ 这是 WebSocket 的配置，SSE 不需要，而且硬编码有害
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";

问题出在第二行硬编码了 "upgrade"：它会给经过这个 location 的所有请求都带上 Connection: upgrade，包括根本没有 Upgrade 头的普通请求和 SSE 请求。Connection 是逐跳（hop-by-hop）首部，被这么滥用会破坏到上游的 keepalive，某些上游实现还会因此行为异常。

正确的写法是用 map 按客户端是否真的请求升级来取值：

# http 块内
map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

# location 内
proxy_http_version 1.1;
proxy_set_header Upgrade    $http_upgrade;
proxy_set_header Connection $connection_upgrade;

如果这个 location 只服务 SSE、完全没有 WebSocket，那更简单——两行都不要写，改成让 nginx 复用到上游的连接：

proxy_http_version 1.1;
proxy_set_header Connection "";

请求路径上真实存在的五个缓冲点

第五个缓冲点最坑人，所以单独强调：curl 默认会缓冲输出。用不带 -N 的 curl 去验证流式，看到的永远是"一次性返回"，无论服务端配得对不对。排查流式问题的第一条纪律是所有 curl 都加 -N（等价于 --no-buffer）。

症状长什么样

用 curl 的计时字段可以把这件事量化，不用凭感觉：

curl -N -o /dev/null -s \
  -w "首字节 %{time_starttransfer}s / 总计 %{time_total}s\n" \
  -H "Authorization: Bearer $KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"gpt-4o-mini","stream":true,"messages":[{"role":"user","content":"数到二十"}]}' \
  https://your-domain/v1/chat/completions

• 首字节 ≈ 总计 → 被完整缓冲了
• 首字节 ≪ 总计 → 流式正常

另一个免费信号在响应头里：

curl -N -D - -o /dev/null -s ... | grep -iE 'content-length|transfer-encoding|content-type'

出现 Content-Length 就说明响应被完整缓冲过——只有知道全部长度才能写出这个头。正常流式应该是 Transfer-Encoding: chunked（HTTP/1.1）或 HTTP/2 的分帧，加上 Content-Type: text/event-stream。

三层二分排查法

不要直接去猜哪一层，按下面这棵树走，两三条命令就能定位。核心思路是从最里层往外逐层加一跳，第一次出问题的那跳就是元凶。

nginx 侧的完整配置

location /v1/ {
    proxy_pass http://127.0.0.1:3000/v1/;

    # 关掉响应缓冲 —— 解决问题的主开关
    proxy_buffering    off;
    proxy_request_buffering off;
    proxy_cache        off;

    # gzip 压缩也会攒数据，流式 location 里必须关
    gzip               off;

    # chunked 需要 HTTP/1.1；清空 Connection 让 nginx 复用上游连接
    proxy_http_version 1.1;
    proxy_set_header   Connection "";

    # 长生成会超过默认的 60s，放宽读超时
    proxy_read_timeout 600s;
    proxy_send_timeout 600s;

    proxy_set_header   Host      $host;
    proxy_set_header   X-Real-IP $remote_addr;
}

几个容易漏的点：

• gzip off 不是可选项。 nginx 的 gzip 模块要攒够数据才能压缩，开着它等于重新引入缓冲。很多人只关了 proxy_buffering 就以为完事，结果症状减轻但没消失，就是 gzip 在作祟。
• proxy_read_timeout 默认 60 秒。 长上下文生成很容易超，超了会收到截断的响应或 504，且现象酷似"流式坏了"。
• proxy_request_buffering off 管的是请求方向，上传大 prompt 时有用，和响应流式无关但顺手一起配。

不想改 nginx 配置？用响应头

如果你没有 nginx 的配置权限，或者不想为一个接口改全局配置，应用可以自己让 nginx 关掉缓冲——返回这个响应头：

X-Accel-Buffering: no

nginx 识别这个头并对该响应禁用缓冲。这是 nginx 特有的机制，非常实用：开关从运维侧移到了应用侧，随代码走，不会因为换机器忘配而复发。

Caddy 侧

Caddy 的 reverse_proxy 对 text/event-stream 会自动刷新，多数情况下开箱即用。如果确实需要强制：

your-domain.com {
    reverse_proxy 127.0.0.1:3000 {
        flush_interval -1
    }
}

flush_interval -1 表示每次写入立即刷新。另外 Caddy 默认会对文本类型启用压缩，如果显式配了 encode gzip，记得把流式路径排除掉，理由和 nginx 的 gzip off 一样。

应用侧：反代配对了也可能不流式

如果排查树的第一步就不通过，那是应用自己没有 flush。反代关掉缓冲只是"不主动攒"，它没法把应用攒着不发的数据变出来。Go 里的标准写法：

func stream(w http.ResponseWriter, r *http.Request) {
    flusher, ok := w.(http.Flusher)
    if !ok {
        http.Error(w, "streaming unsupported", http.StatusInternalServerError)
        return
    }

    w.Header().Set("Content-Type", "text/event-stream")
    w.Header().Set("Cache-Control", "no-cache")
    w.Header().Set("X-Accel-Buffering", "no") // 顺手把 nginx 也关掉

    for chunk := range chunks {
        fmt.Fprintf(w, "data: %s\n\n", chunk)
        flusher.Flush() // 少了这行，前面全白配
    }
    fmt.Fprint(w, "data: [DONE]\n\n")
    flusher.Flush()
}

注意 w.Header().Set 必须在第一次 Write 之前调用，否则不生效——这是另一个安静失败的经典来源。

相关阅读

• new-api 部署选型：2G 小内存机器上裸二进制比 Docker 省多少 —— 反代前面那一层，部署形态怎么选
• API 中转站的限流为什么不能信 X-Forwarded-For —— 本文配置里那行 X-Real-IP 为什么不能省