Go httptest.NewRequest 构造的请求为什么带有固定 RemoteAddr

我第一次给 HTTP handler 写单元测试时，看到 r.RemoteAddr 总是同一个值，第一反应是测试环境把请求“发自本机”了。后来才发现，httptest.NewRequest 根本没有建立一条真实连接：它直接构造一个适合传给 handler 的入站请求，固定地址只是为了让测试字段完整且稳定。

官方地址：https://pkg.go.dev/net/http/httptest#NewRequest；实现源码：https://go.dev/src/net/http/httptest/httptest.go。

httptest.NewRequest 里的 RemoteAddr 是测试默认值 192.0.2.1:1234，不是客户端真实地址，也不代表测试程序占用了这个网络端点。只有在测试业务确实依赖来源地址时，才应显式覆盖它；如果要观察真实连接产生的请求，则应使用测试服务器路径。

先看 NewRequest 构造的请求是什么

NewRequest(method, target, body) 的定位是“构造一个入站请求值”。它把方法、请求目标和请求体整理成 *http.Request，然后由测试代码直接调用 handler。中间没有监听端口、TCP 客户端，也没有操作系统分配的对端地址。

这也是它和 net/http.NewRequest 容易混淆的地方：后者更偏向创建客户端准备发送的请求；httptest.NewRequest 的文档明确说它适合传给 http.Handler 测试。

下面这个例子故意把字段打印出来，重点不是验证某台机器的网络环境，而是展示构造函数给 handler 的对象形状：

package main

import (
	"fmt"
	"net/http/httptest"
)

func main() {
	// 这里不会监听端口；请求对象会直接交给测试中的 handler。
	req := httptest.NewRequest("GET", "/profile?id=7", nil)

	// 这些字段来自测试请求的构造语义，不是一次真实网络握手的结果。
	fmt.Println(req.Method)
	fmt.Println(req.URL.Path)
	fmt.Println(req.Host)
	fmt.Println(req.Proto)
	fmt.Println(req.RemoteAddr)
}

对于路径形式的 target，默认 Host 是 example.com；Proto 固定为 HTTP/1.1。因此测试断言应该围绕 handler 需要的请求语义写，而不要把它当作一次真实客户端请求的抓包结果。

理解固定 RemoteAddr 的来源和边界

当前 Go 源码在构造请求时明确设置了 req.RemoteAddr = "192.0.2.1:1234"，并在旁边说明 192.0.2.0/24 是 RFC 5737 的 TEST-NET 文档示例地址，只用于文档和示例。这个选择很有用：它看起来像一个完整的“IP:端口”字段，却不会被误认为某个真实用户的公网来源。

所以，下面几种说法要区分开：

如果你的中间件只是要求字段非空，直接使用默认值即可。如果业务逻辑要从地址中提取 IP、判断内网范围或生成审计记录，那么默认值只能作为一个普通测试输入，不能冒充真实来源。

分清 target、Host、Proto 和 TLS 的关系

很多“RemoteAddr 为什么固定”的排查，实际上是把不同字段混成了一个网络概念。target 决定请求目标的解析方式，Host 是请求的主机语义，Proto 是测试请求声明的 HTTP 协议版本，RemoteAddr 则是一个测试用的来源地址字段。

package main

import (
	"fmt"
	"net/http/httptest"
)

func showTarget(target string) {
	// target 可以是路径，也可以是绝对 URL；两种形式的 Host 规则不同。
	req := httptest.NewRequest("GET", target, nil)

	// https 目标会得到非 nil 的测试 TLS 状态，但仍不是一次真实握手。
	fmt.Printf("target=%q host=%q proto=%q remote=%q tls=%t\n",
		target, req.Host, req.Proto, req.RemoteAddr, req.TLS != nil)
}

func main() {
	showTarget("/health")
	showTarget("https://api.example.test/health")
}

可以按下面的规则读结果：

• 传入 /health 这样的路径时，Host 使用测试默认的 example.com。
• 传入绝对 URL 时，URL 中的主机名会成为请求的 Host。
• 协议字段仍然是 HTTP/1.1；目标是 https 时，TLS 字段会被设置为非空的测试值。
• 无论 target 使用路径还是绝对 URL，RemoteAddr 都沿用测试构造的默认地址。

因此不要用 RemoteAddr 推断 URL 的主机，也不要用 req.TLS != nil 断言已经完成了真实 TLS 握手。它们分别表达测试请求中的来源字段和 HTTPS 语义。

需要来源地址时，什么时候覆盖字段

覆盖 RemoteAddr 是可以的，因为它只是一个可写的 http.Request 字段。关键是让覆盖值服务于明确的测试场景，而不是为了让测试“看起来像真的”。例如，来源解析函数要处理 IPv6、带端口地址或代理转发后的输入时，可以直接准备代表该场景的字符串。

package main

import (
	"net/http/httptest"
	"strings"
)

func classifySource(remoteAddr string) string {
	// 生产代码通常会在这里解析地址；示例只保留一个可观察的分支。
	if strings.HasPrefix(remoteAddr, "10.") {
		return "private"
	}
	return "other"
}

func main() {
	req := httptest.NewRequest("GET", "/", nil)

	// 只有测试“来源分类”时才覆盖，避免把默认哨兵误当成业务事实。
	req.RemoteAddr = "10.24.8.9:43120"
	_ = classifySource(req.RemoteAddr)
}

这里的覆盖值只是测试输入，不能让测试变成真实网络测试。建议把断言写在“给定某个来源字符串，业务返回什么”这一层；若要验证连接建立、客户端地址生成、TLS 握手或代理转发链，则应选择 httptest.Server 等更接近网络边界的测试方式，而不是继续修改 NewRequest 返回值。

把单元测试和网络行为分成两条线

我现在会先问一个很具体的问题：这个测试是在验证 handler 对请求字段的处理，还是在验证请求通过网络到达服务器后的行为？前者用 httptest.NewRequest 更直接；后者才需要让客户端发送请求到测试服务器。两种方式都叫 HTTP 测试，但它们承担的边界不同。

结论与常见问题

httptest.NewRequest 固定 RemoteAddr，是因为它构造的是可重复的入站请求测试值，而不是从 socket 读取真实对端。192.0.2.1:1234 属于文档示例用的 TEST-NET 地址；它的职责是填充请求字段，方便 handler 在没有真实连接的情况下运行。

记住三点就够了：普通 handler 测试直接接受默认值；测试来源判断时显式覆盖 RemoteAddr；要验证网络边界时换用测试服务器，不要把单元测试请求改造成“伪真实连接”。

为什么不是 127.0.0.1？

因为 NewRequest 不表示请求来自本机回环接口。使用文档专用的 TEST-NET 地址，可以避免把测试默认值和某台机器的实际网络拓扑混为一谈。

绝对 URL 会改变 RemoteAddr 吗？

不会。绝对 URL 主要影响 URL 和 Host；RemoteAddr 仍是构造函数设置的测试默认值。

可以直接修改 req.RemoteAddr 吗？

可以。它适合测试 IP 提取、来源分类和审计字段等纯业务逻辑，但修改后的值仍然只是测试输入，不是网络层证据。

什么时候不该用 NewRequest？

当测试目标包含客户端真正发起请求、服务端接收连接、TLS 或代理链路时，不要只构造 *http.Request；应使用 httptest.Server 相关 API，让测试覆盖网络边界。