Go pprof HTTP 端点暴露后怎样限制访问范围

Go 的 net/http/pprof 通常通过导入副作用把 /debug/pprof/ 相关处理器注册到默认 mux。真正需要限制的不是“把路径改得复杂一点”，而是诊断服务的网络边界：公网业务服务使用自己的 mux，pprof 使用独立 mux，并优先只监听回环地址；必须远程采集时，再在内网代理、TLS 和认证之后开放。

官方资料：https://pkg.go.dev/net/http/pprof

最稳妥的组合是“业务入口不挂 pprof + pprof 独立监听 + 网络边界优先 + 远程访问叠加认证”。隐藏 /debug/pprof/ 路径或只检查一个请求头，都不能替代监听地址和访问控制。

• 默认行为：导入 net/http/pprof 会注册处理器，默认路径以 /debug/pprof/ 开头。
• 隔离方式：自建 http.ServeMux，只把需要的 pprof handler 放进去，不复用公网业务 mux。
• 网络限制：本机调试优先绑定 127.0.0.1；多实例环境可放在私网或诊断代理后。
• 采集边界：CPU profile 和 trace 带有采集时长，heap、goroutine 等端点也应避免被普通用户随意调用。

先判断 pprof 为什么会出现在公网入口

pprof 包的初始化会把处理器注册到 http.DefaultServeMux，所以代码里只要出现 import _ "net/http/pprof"，再把默认 mux 交给公网服务器，就可能让诊断路径跟着业务端口一起出现。官方文档也说明：如果应用不使用 DefaultServeMux，就需要把处理器注册到自己使用的 mux。

这意味着排查要先看两件事：业务服务器的 Handler 是否为 nil，以及业务路由是否直接使用了默认 mux。把端口从 6060 换成另一个公网端口，或者把路径改成不容易猜的字符串，都不能改变“谁能连到这个监听器”的事实。

用独立 mux 只暴露需要的端点

第一步是不要让 pprof 共享业务服务的 mux。下面的示例保留常用端点，同时把诊断服务绑定到本机回环地址；业务服务器仍使用自己的 mux。这里没有运行示例，代码只用于说明处理器和监听器的职责关系。

package main

import (
    "log"
    "net/http"
    "net/http/pprof"
    "time"
)

// newPPROFMux 只负责诊断端点，避免把 DefaultServeMux 当作业务路由器。
func newPPROFMux() *http.ServeMux {
    mux := http.NewServeMux()

    // Index 负责 /debug/pprof/ 目录及其下的剖析入口。
    mux.Handle("/debug/pprof/", http.HandlerFunc(pprof.Index))
    mux.Handle("/debug/pprof/cmdline", http.HandlerFunc(pprof.Cmdline))
    mux.Handle("/debug/pprof/profile", http.HandlerFunc(pprof.Profile))
    mux.Handle("/debug/pprof/symbol", http.HandlerFunc(pprof.Symbol))
    mux.Handle("/debug/pprof/trace", http.HandlerFunc(pprof.Trace))

    // 这些名称对应 runtime/pprof 提供的标准 profile。
    for _, name := range []string{"heap", "goroutine", "allocs", "block", "mutex", "threadcreate"} {
        mux.Handle("/debug/pprof/"+name, pprof.Handler(name))
    }
    return mux
}

func main() {
    // 业务 mux 不接收 pprof，公网端口只处理业务请求。
    appMux := http.NewServeMux()
    appMux.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
        w.WriteHeader(http.StatusNoContent)
    })

    go func() {
        // 回环监听把第一层访问范围限制在本机。
        diagnosticServer := &http.Server{
            Addr:              "127.0.0.1:6060",
            Handler:           newPPROFMux(),
            ReadHeaderTimeout: 5 * time.Second,
        }
        log.Println(diagnosticServer.ListenAndServe())
    }()

    log.Fatal(http.ListenAndServe(":8080", appMux))
}

如果只需要临时查看本机进程，回环监听通常已经比公网绑定更合适。若应用运行在容器中，要注意容器内的 127.0.0.1 只代表容器自身；需要从宿主机或诊断 sidecar 访问时，应明确设计网络命名空间和端口转发，而不是直接把端口发布到所有网卡。

远程采集时把认证放在网络边界之后

生产环境有时需要从专用采集机获取 profile。这时可以让 pprof 只监听私网地址，或只对内网代理开放，再在应用或代理层加认证。下面的中间件展示基本的认证位置；实际传输必须使用 TLS，账号和密码也应从密钥系统或环境注入，不能写死在源码里。

package main

import (
    "crypto/subtle"
    "net/http"
    "os"
)

// protect 只负责认证，不负责判断请求是否来自可信网络。
func protect(next http.Handler) http.Handler {
    expectedUser := os.Getenv("PPROF_USER")
    expectedPass := os.Getenv("PPROF_PASS")

    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        user, pass, ok := r.BasicAuth()
        // 常量时间比较减少直接比较带来的时序差异；TLS 才能保护凭据传输。
        userOK := subtle.ConstantTimeCompare([]byte(user), []byte(expectedUser)) == 1
        passOK := subtle.ConstantTimeCompare([]byte(pass), []byte(expectedPass)) == 1
        if !ok || !userOK || !passOK {
            w.Header().Set("WWW-Authenticate", `Basic realm="pprof"`)
            http.Error(w, "unauthorized", http.StatusUnauthorized)
            return
        }
        next.ServeHTTP(w, r)
    })
}

认证不能替代网络限制：Basic Auth 没有 TLS 时会把凭据暴露在传输链路上，代理也可能重写 RemoteAddr，因此不要只根据一个来自客户端的头部判断来源。比较稳的部署关系是：采集机或跳板机进入私网，代理完成 TLS 和身份校验，应用侧再保留一层必要的认证或来源限制。

不同 profile 要设置不同的采集边界

限制访问范围后，还要限制采集动作本身。heap 适合观察内存分配样本，goroutine 用于查看当前 goroutine 栈，block 和 mutex 需要先启用相应运行时剖析；profile?seconds=N 会持续采集 CPU profile，trace?seconds=N 也会占用一段采集窗口。

因此可以把访问策略拆成三档：

1. 本机临时诊断：只绑定回环地址，手工执行一次采集，完成后关闭诊断服务。
2. 内网按需诊断：只允许专用来源访问，使用 TLS 和短时凭据，CPU profile 与 trace 设置明确时长。
3. 持续观测：通过受控采集器定期选择实例，避免多个高成本 profile 同时运行，并把原始文件保存到受限存储。

官方诊断文档提醒，某些剖析会互相干扰，例如精确内存剖析会影响 CPU profile，阻塞剖析也会影响调度跟踪。把“能访问”与“允许怎样采集”分开设计，才能避免诊断入口变成新的性能风险。

上线前的 pprof 访问清单

可以用下面的清单复查部署设计：

• 公网业务服务器是否使用自定义 mux，而不是隐式使用 http.DefaultServeMux。
• pprof 是否运行在独立的监听器上，监听地址是否只覆盖本机或明确的私网。
• 是否把 TLS、认证、来源网络和代理转发规则分开考虑。
• 是否只开放实际需要的 profile，是否限制 CPU profile 与 trace 的时长。
• 是否记录谁在什么时间采集了哪个实例，并在诊断结束后撤销临时访问权限。

Go pprof HTTP 访问范围常见问题

只把 pprof 路径改掉，能算限制访问吗？

不能。路径改名只能降低偶然发现概率，监听地址、网络 ACL、代理和认证才决定访问范围。

为什么导入 pprof 后业务端口也出现了诊断路径？

常见原因是服务器使用了 http.DefaultServeMux，而 pprof 初始化时把处理器注册到了这个默认 mux。改用自定义业务 mux，并让 pprof 只注册到独立 mux，可以切断这条隐式关系。

pprof 一定要完全禁止在生产环境使用吗？

不一定。Go 官方诊断文档说明生产环境可以采集 profile，但部分 profile 会产生开销。关键是把端点放在受控网络中，限制采集者、时长和并发，并按实际负载评估代价。

归根结底，限制 Go pprof HTTP 端点要先做入口隔离，再做网络限制，最后才是认证和 profile 级策略。只要业务 mux、诊断 mux 和监听器的职责清楚，pprof 就能作为受控的工程诊断工具，而不是跟随公网业务端口一起暴露的隐形管理接口。