Go httputil.DumpRequestOut 怎样调试请求头而不泄露密钥

如果你想知道 Go 的 HTTP 客户端准备发出什么请求，httputil.DumpRequestOut 是很直接的工具。它面向 outgoing client request，除了 http.Request 里已有的内容，还会把标准 http.Transport 可能补上的请求头纳入输出。

官方地址：https://pkg.go.dev/net/http/httputil#DumpRequestOut

但它不会替你判断哪些字段是秘密。调试请求时，建议把“真实发送对象”和“日志副本”分开：真实请求照常交给客户端，副本只保留排查所需信息，并对 Authorization、Cookie 以及项目自定义密钥头做脱敏。

DumpRequestOut 和 DumpRequest 有什么区别

DumpRequest 更偏向服务端收到的请求；DumpRequestOut 专门面向客户端即将发出的请求。第二个参数是 body bool：传入 true 会尝试把请求体也纳入结果，传入 false 则只看请求行和请求头。

另一个容易忽略的点是，结果是接近 HTTP/1.x 线路形式的调试表示，不是 HTTP/2 的原始二进制抓包。它适合回答“客户端准备发送哪些字段”，不适合当成完整网络证据。

先复制请求，再处理敏感头

不要为了打印日志直接修改真正要发送的 req.Header。那样做可能把脱敏后的值带到服务端。更稳妥的做法是只复制请求头，脱敏发生在副本上；如果要打印请求体，也应先确认体积和敏感内容都在可控范围内。

package main

import (
    "fmt"
    "net/http"
    "net/http/httputil"
    "strings"
)

// redactHeaders 只修改 Header 的副本，避免影响真正发送的请求。
func redactHeaders(src http.Header) http.Header {
    dst := src.Clone()
    // 认证、Cookie 和项目密钥统一使用固定占位符。
    for _, key := range []string{"Authorization", "Cookie", "X-Api-Key"} {
        if dst.Get(key) != "" {
            dst.Set(key, "[REDACTED]")
        }
    }
    return dst
}

func dumpSafe(req *http.Request) (string, error) {
    // Clone 复制请求元数据；Body 仍需按文章后面的规则单独控制。
    copyReq := req.Clone(req.Context())
    copyReq.Header = redactHeaders(req.Header)
    // false 表示本例不把可能含业务数据的请求体写入日志。
    raw, err := httputil.DumpRequestOut(copyReq, false)
    if err != nil {
        return "", fmt.Errorf("dump outgoing request: %w", err)
    }
    return strings.TrimSpace(string(raw)), nil
}

这个示例的关键不是把所有头都删除，而是明确一份脱敏清单。没有出现在清单里的字段仍可能含有隐私或业务标识，所以生产项目最好把清单放在统一的日志组件中，并允许按环境关闭完整输出。

DumpRequestOut 看见了哪些请求头

调用发生在客户端请求上下文中，因此输出可能包含 Transport 为请求补充的字段，例如默认的 User-Agent 或 Accept-Encoding。这样它比直接遍历调用方设置的 Header 更接近客户端最终准备发送的形态。

如果你只想观察头部，可以把 body 设为 false。如果确实要排查请求体编码，再考虑设为 true，并先确认内容不是密码、令牌、个人信息或超大上传内容。

// 仅输出脱敏后的请求头，避免把业务请求体写入调试日志。
safe, err := dumpSafe(req)
if err != nil {
    // 记录错误类型即可，避免在失败路径中追加原始请求内容。
    logger.Printf("request dump skipped: %v", err)
} else {
    logger.Printf("outgoing request:\n%s", safe)
}

常见误区和边界

• 误区一：把 DumpRequestOut 当成抓包。它是库生成的调试表示，HTTP/2 请求也会以 HTTP/1.x 形式呈现，不能替代网络层工具。
• 误区二：只遮住 Authorization。Cookie、签名参数、自定义 Token 头和请求体同样可能敏感，应按业务数据分类处理。
• 误区三：默认把 body 设为 true。调试上传接口时，body 可能很大，也可能包含用户提交数据。没有明确需要时优先使用 false。
• 误区四：修改原请求后再发送。日志副本和发送对象必须分离，否则脱敏动作可能改变真实请求语义。

可以把规则简化成一张速查表：

结论

安全使用 DumpRequestOut 的核心只有三步：复制请求、脱敏副本、按需决定是否包含 body。这样既能看到 Transport 补充的客户端请求头，又不会为了排查一个 Header 问题，把真实认证信息写进日志。

相关问题

• 为什么直接打印 req.Header 看不到 Transport 后补的字段？
• 请求体需要调试时，怎样设置大小上限并避免记录原文？
• 什么时候应该使用服务端的 DumpRequest 而不是 DumpRequestOut？