Go 服务的 pprof 能直接暴露公网吗？排障入口上线前的安全判断

不要把 Go 服务的 /debug/pprof/ 直接暴露到公网。pprof 和 trace 是排查 CPU、内存、goroutine、锁竞争和调度等待的利器，但它们看到的是运行时现场，不是给外部用户访问的普通接口。线上需要它时，更稳的做法是放在本机或受控内网，通过开关、鉴权代理和短时采集完成排障，采完以后关掉入口并留下记录。

真实事故里，这个判断常常发生在接口已经变慢的时候。日志里只有“请求耗时 2.3s”，值班同学想立刻抓一份 profile；如果为了省事把 6060 端口直接映射出去，后面要担心的就不只是性能问题，还多了一个暴露运行时信息的安全入口。

先分清：pprof 是排障入口，不是业务接口

pprof 的价值很直接：服务慢了、CPU 飙了、内存涨了、goroutine 堆住了，它能把“感觉哪里不对”变成可下载、可复盘的数据。常见的 /debug/pprof/profile 可以抓 CPU 采样，/debug/pprof/heap 可以看堆分配，/debug/pprof/goroutine 可以看 goroutine 状态，/debug/pprof/trace 可以抓一段运行时轨迹。

问题也在这里：这些数据越有排障价值，越说明它不该随便给外部访问。业务接口的目标是稳定返回结果；pprof 入口的目标是把服务内部状态摊开给工程师看。只要把这两者分开，很多上线争议就清楚了：能不能用 pprof，不是语法问题，而是入口边界和操作权限问题。

风险从哪里来：公网暴露会放大运行时细节

公开暴露 /debug/pprof/ 的风险，通常不是“别人点一下页面服务就坏了”这么简单，而是运行时细节被看见之后，攻击面变得更清楚。

• 服务结构被推出来。 goroutine 栈、函数名、包路径和热点调用，可能让外部人员看出服务模块和关键链路。
• 负载状态被观察到。 CPU、heap、block、mutex 等数据会反映服务忙闲、内存压力和竞争点。
• 采集动作也有成本。 CPU profile 和 trace 都会消耗资源；事故现场已经紧张时，长时间采集可能让抖动更明显。
• 入口容易被遗忘。 临时开一个端口，排完障忘了关，是线上系统里很常见的尾巴。

所以判断标准可以更朴素一点：如果这个地址不是普通用户该访问的地址，就不要用普通业务接口的方式把它放出去。

安全接入：把采集入口收在可控范围内

线上确实需要 pprof 和 trace，尤其是偶发性能问题只在生产流量下出现时。合理做法不是完全禁用，而是把入口收在可控范围内。

• 优先绑定 127.0.0.1，需要远程采集时走跳板机或临时隧道。
• 必须经过内网访问时，放在管理网段，并在反向代理层加鉴权和访问白名单。
• 入口用配置开关控制，默认关闭，需要排障时按发布流程打开。
• 采集窗口要短，CPU profile 常见是几十秒，trace 更要控制时间。
• 谁打开、什么时候打开、采了什么、什么时候关闭，都要写进操作记录。

代码示例：单独监听本机排障端口

下面这个写法把业务端口和排障端口分开。pprof 监听在 127.0.0.1:6060，外部流量不会直接打到这个地址；真正需要采集时，可以在机器上本地运行命令，或者通过受控通道访问。

package main

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

func main() {
    mux := http.NewServeMux()
    mux.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
        _, _ = w.Write([]byte("ok"))
    })

    go func() {
        log.Println("pprof listens on 127.0.0.1:6060")
        if err := http.ListenAndServe("127.0.0.1:6060", nil); err != nil {
            log.Println("pprof server stopped:", err)
        }
    }()

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

采集时可以按问题类型选择入口。接口 CPU 突然打满，先抓一段 CPU profile；内存持续上涨，再看 heap；请求偶发等待很久，trace 更容易把等待链路摊开。

go tool pprof http://127.0.0.1:6060/debug/pprof/profile?seconds=30
go tool pprof http://127.0.0.1:6060/debug/pprof/heap
curl -o trace.out 'http://127.0.0.1:6060/debug/pprof/trace?seconds=5'
go tool trace trace.out

采集 trace 时，时间窗口别贪长

CPU profile 可以帮你看热点函数，trace 更像一段时间里的现场录像：goroutine 什么时候创建、什么时候等待、什么时候恢复、调度器怎么切换，都能在工具里看到。它适合分析“为什么请求等在那里”，但不适合长时间一直开着抓。

生产排障里，我更愿意先抓 5 秒到 10 秒的 trace，看能不能覆盖异常窗口。如果问题复现频率低，就配合业务日志里的 request id、慢接口时间点和监控曲线，挑更接近异常的窗口，而不是一上来抓很长时间。

上线前检查：发布单里要写清的几件事

排障入口最怕靠口头约定。上线前可以用这份清单压一下风险：

• 入口地址：是否只绑定本机或管理网段，确认没有被公网负载均衡转发。
• 访问权限：是否有鉴权、白名单或跳板限制，是否能查到访问记录。
• 开关状态：默认是开还是关，谁有权限临时开启。
• 采集时长：CPU profile、heap、goroutine、trace 分别允许采多久。
• 关闭动作：事故处理结束后谁确认关闭，在哪里留痕。
• 留存范围：采集文件放在哪里，多久清理，是否避免进入公开工单或截图。

相关问题

pprof 完全不能在线上开吗？

可以在线上用，但不建议裸露公网。线上问题最需要真实流量下的证据，关键是入口要受控、采集要短、记录要完整。

只绑定 127.0.0.1 就一定安全吗？

绑定本机能挡住大多数外部直接访问，但还要看部署方式。容器网络、端口映射、调试代理和运维脚本都可能改变入口边界，发布前要实际确认访问路径。

trace 和 pprof 应该先用哪个？

CPU 或内存问题先看 pprof，等待、阻塞、调度和请求链路抖动更适合看 trace。事故现场不要一次抓一堆文件，先按症状选择最能回答问题的证据。

能不能把 pprof 挂在业务路由下面？

不建议混在普通业务路由里。最好单独端口、单独开关、单独权限，避免被网关规则、缓存规则或外部扫描误触。

总结

Go 服务的 pprof 和 trace 值得接入，但它们应该被当作受控排障入口，而不是普通页面。把地址收在本机或管理网段，给入口加权限，采集时间控制住，排完障及时关闭，这样既能拿到 CPU、内存、goroutine 和调度等待的证据，也不会为了排一个性能问题，又留下一个新的安全口子。