Go HTTP服务器需分层限流：连接层用自定义limitedListener控制并发连接数，请求层用rate.Limiter按IP/路径分组限流，超时需设ReadTimeout/ReadHeaderTimeout，真实IP需校验可信代理头。
Go HTTP 服务器怎么限制并发连接数
直接用 net/http.Server 的 MaxConns 字段？不行——它从 Go 1.19 才加，且只在启用了 HTTP/2 时生效，对大多数 HTTP/1.1 场景无效。真实生产中得自己兜底。
推荐做法是用 net.Listener 包一层限流逻辑，比如用带缓冲的 channel 控制同时接受的连接数：
type limitedListener struct {
net.Listener
sem chan struct{}
}
<p>func (l *limitedListener) Accept() (net.Conn, error) {
select {
case l.sem <- struct{}{}:
conn, err := l.Listener.Accept()
if err != nil {
<-l.sem
return nil, err
}
return &limitedConn{Conn: conn, sem: l.sem}, nil
default:
return nil, errors.New("too many connections")
}
}- 注意
Accept()返回前必须确保连接已建立，否则sem泄漏；所以封装limitedConn在Close()时归还信号 - 别把缓冲大小设成 CPU 核数——这是常见误解；应基于内存和文件描述符上限算，比如
ulimit -n减去预留系统连接后取 70% - 该方案不防慢速攻击（如 Slowloris），仅控“连接数”，不是“请求数”
HTTP handler 层怎么加请求级限流
连接数控制挡不住高频短连接，真正要压垮服务的是单位时间内的请求数。别手写令牌桶——用现成的 golang.org/x/time/rate 最稳。
rate.Limiter 默认是“请求到达即判断”，但 Web 场景常需按 IP 或路由分组限流，得自己套 map + sync.Map：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
var limiters = sync.Map{} // key: ip + path, value: *rate.Limiter
<p>func getLimiter(key string) <em>rate.Limiter {
if lim, ok := limiters.Load(key); ok {
return lim.(</em>rate.Limiter)
}
lim := rate.NewLimiter(rate.Every(1*time.Second), 100)
limiters.Store(key, lim)
return lim
}- key 拼接别漏转义，比如
path含/、ip含:，建议用fmt.Sprintf("%s:%s", ip, strings.ReplaceAll(path, "/", "_")) -
rate.Every和burst不是越大越好：burst 过大会让突发流量打穿下游；every 过小会导致大量请求被秒拒，客户端重试反而放大压力 - 别在中间件里每次 new 一个
Limiter——没共享就等于没限流
为什么 http.TimeoutHandler 对 DDoS 效果有限
它只管单个 handler 执行超时，不解决连接堆积、TLS 握手耗尽 CPU、或请求头巨长占满 buffer 的问题。
真实 DDoS 流量里，大量请求卡在 TLS 握手阶段或发一半就断，TimeoutHandler 根本没机会触发。这时候得靠更前置的防护：
- 用
http.Server.ReadTimeout和ReadHeaderTimeout缩短握手和 header 解析窗口（建议 ≤5s） - 禁用 HTTP/2 如果不用 gRPC 或 Server-Sent Events——HTTP/2 的多路复用在攻击下更容易耗尽 goroutine
- 如果用反向代理（如 Nginx），把连接限制、TLS 卸载、IP 封禁全交给它，Go 服务只处理干净流量
限流日志里看不到真实 IP 怎么办
只要前面挂了 CDN 或负载均衡，r.RemoteAddr 就是代理 IP，直接限流会误伤整片用户。
必须解析 X-Forwarded-For，但不能无条件信任——它可被伪造。安全做法是只信任你可控的上一跳 IP：
func getClientIP(r *http.Request, trusted []string) string {
ip := r.Header.Get("X-Forwarded-For")
if ip == "" {
return r.RemoteAddr
}
for _, t := range trusted {
if t == realRemoteIP(r) { // 自行实现获取真实 remote IP
parts := strings.Split(ip, ",")
return strings.TrimSpace(parts[0])
}
}
return r.RemoteAddr
}- trusted 列表必须硬编码或从配置加载，不能从请求里读；否则攻击者塞个
X-Forwarded-For: 127.0.0.1就绕过所有限流 - 别用
net.ParseIP做简单校验——IPv6 带端口、IPv4 带空格都可能被放行；用net.ParseIP(strings.TrimSpace(ip)) != nil更稳妥 - 如果用了云厂商 LB（如 AWS ALB），优先用其专有 header（如
X-AMZN-Trace-Id配合源 IP 白名单），比通用 header 更可靠
限流不是加个中间件就完事；连接数、请求数、超时、真实来源，四个层面要各自守住，又得互相不冲突。最容易被忽略的是：没做连接层限流时，光在 handler 里限流，等于守城门却不管城墙有没有被挖穿。
