Golang SSRF防护实战：从原理到代码实现的安全HTTP客户端

1. 项目概述：为什么Golang开发者必须重视SSRF防护

如果你在用Golang开发Web服务，尤其是处理用户提供的URL、图片上传、Webhook回调或者任何需要代理外部请求的功能，那么SSRF（Server-Side Request Forgery，服务端请求伪造）绝对是你不能忽视的安全漏洞。这个漏洞的可怕之处在于，攻击者可以利用你的服务器作为跳板，去探测甚至攻击内网中那些本不该暴露在公网的服务，比如数据库、Redis、管理后台，甚至是云服务商提供的元数据接口。我见过太多因为一个简单的图片上传接口没做好校验，导致整个内网被“打穿”的案例。

在Golang社区里，大家常常津津乐道于其高性能和简洁的并发模型，但安全防护的细节却容易被忽略。 net/http 包用起来是顺手，但默认的 http.Client 就是个“傻白甜”，你给它什么URL它就请求什么，根本不会帮你判断这个请求目的地是不是你公司的内网服务器。网上很多教程只教你怎么发起请求，却很少系统地讲怎么安全地发起请求。这就是我想写这篇内容的原因——结合我这些年踩过的坑和实战经验，给你一套从原理到代码，可以直接抄作业的Golang SSRF防护实现方案。

2. SSRF攻击原理与Golang中的风险点剖析

2.1 SSRF到底是如何发生的？

简单来说，SSRF就是“借刀杀人”。攻击者自己没有权限直接访问目标内网资源（比如 192.168.1.100:8080 上的一个管理界面），但他发现你的应用有一个功能，可以接受一个URL参数，然后服务器会去请求这个URL并返回内容（比如文章开头提到的“通过URL上传图片”功能）。于是，攻击者把这个内网地址作为参数提交给你。你的服务器程序毫无戒备地去请求了 http://192.168.1.100:8080/admin ，成功访问到了内网资源，再把返回的内容（可能是管理页面的HTML源码）返回给攻击者。这样一来，攻击者就通过你的服务器这把“刀”，杀入了内部网络。

在Golang中，风险的核心就在于 http.Get 、 http.Post 以及 http.Client 的默认行为。它们只负责完成HTTP请求，至于这个请求是去往谷歌还是去往你隔壁工位同事的测试服务器，它一概不管。

2.2 Golang场景下的高危攻击向量

除了最基础的直接使用内网IP，攻击者在面对一个用Golang写的服务时，会尝试更多花样来绕过你可能存在的简单防护。

2.2.1 IP地址的“七十二变”

很多新手防护SSRF，第一反应就是写个正则，过滤 192.168. 、 10. 、 172.16. 这些字符串。这太天真了。一个IPv4地址的表示法远不止点分十进制这一种。攻击者完全可以把 192.168.1.1 写成：

• 八进制 ： 0300.0250.01.01 （每个点分部分转换为八进制）
• 十六进制 ： 0xC0.0xA8.0x1.0x1
• 十进制整数 ： 3232235777 （将整个IP地址转换为一个32位整数）
• 混合进制 ： 192.0xA8.0x1.1 （每一段都可以独立采用不同进制）

你的字符串匹配正则，能覆盖所有这些情况吗？更别提IPv6了，它的压缩表示法（如 ::1 代表回环地址）和嵌入IPv4的表示法，会让基于字符串的过滤彻底失效。

2.2.2 利用特殊域名服务

像 xip.io 这样的服务，提供了极简的DNS泛解析。攻击者可以构造 http://192.168.1.1.xip.io 这样的域名，DNS解析后会直接指向 192.168.1.1 。你的程序如果只做一次域名解析然后缓存IP，或者只检查URL字符串中是否包含内网段，就会被轻松绕过。

2.2.3 HTTP重定向攻击

这是非常狡猾的一招。假设你的防护逻辑是这样的：1）解析用户输入的URL；2）DNS解析得到IP；3）判断IP是否为内网；4）如果是外网，则发起请求。 攻击者可以提供一个URL，指向一个他控制的公网服务器 http://attacker.com/redirect 。这个服务器的逻辑是，返回一个 302 Found 或 307 Temporary Redirect 响应，跳转目标指向 http://192.168.1.1/admin 。 你的防护逻辑在第3步检查 attacker.com 的IP是公网，通过。于是程序发起请求，收到重定向响应。默认的 http.Client 会自动跟随重定向，直接向 192.168.1.1 发起第二次请求。而这次请求 跳过了你所有的前置检查 ，攻击成功。

2.2.4 DNS重绑定攻击

这是高阶攻击手法，利用了DNS解析的时机差。攻击者控制了自己的DNS服务器（ ns.attacker.com ），并做了如下配置：

1. 域名 evil.attacker.com 第一次查询时，返回一个公网IP 1.2.3.4 ，并将TTL（生存时间）设置为0。
2. 第二次查询时，返回一个内网IP 192.168.1.1 。

你的防护流程：

1. 用户输入 http://evil.attacker.com/path 。
2. 你的程序进行DNS解析，得到 1.2.3.4 （公网），检查通过。
3. 程序使用 http.Client 正式发起TCP连接。 关键点来了 ：因为上一步DNS结果的TTL=0， http.Client 在建立连接前会 再次进行DNS解析 ！这一次，攻击者的DNS服务器返回了 192.168.1.1 。
4. 程序成功连接到了内网地址。

Golang的 net 包默认没有对DNS结果进行缓存，所以TTL=0会强制每次连接都重新解析，这恰好被攻击者利用。

2.3 为什么Golang需要自定义防护方案？

因为标准库的 http.Client 设计目标是“好用”和“灵活”，而不是“安全”。它把控制权完全交给了开发者。社区中一些常用的HTTP请求库，如 resty 或 gentleman ，本质上也是基于 http.Client 的封装，并没有内置SSRF防护。因此，我们必须自己动手，在 http.Client 的各个关键扩展点上（如 Transport 和 CheckRedirect ）植入安全检查逻辑，打造一个安全的HTTP客户端。

3. 构建核心的SSRF防护客户端

我们的目标是创建一个增强型的 http.Client ，它在发起任何请求前和请求过程中，都能智能地识别并阻断对内网资源的访问。下面我们来一步步实现这个“安全卫士”。

3.1 基石：准确判断IP是否为内网地址

这是所有防护逻辑的基础，必须绝对可靠。我们不能用字符串匹配，必须将主机名解析为标准的 net.IP 对象再进行判断。

package ssrf

import (
    "net"
)

// IsPrivateIP 判断一个 net.IP 对象是否属于私有网络地址。
// 这是防护的核心函数，务必保证其正确性。
func IsPrivateIP(ip net.IP) bool {
    if ip == nil {
        return false
    }

    // 1. 首先检查回环地址 (127.0.0.1/8, ::1)
    if ip.IsLoopback() {
        return true // 回环地址也视为内网，禁止访问
    }

    // 2. 处理IPv4
    if ip4 := ip.To4(); ip4 != nil {
        // 判断是否在RFC 1918定义的私有地址段内
        switch {
        case ip4[0] == 10: // 10.0.0.0/8
            return true
        case ip4[0] == 172 && ip4[1] >= 16 && ip4[1] <= 31: // 172.16.0.0/12
            return true
        case ip4[0] == 192 && ip4[1] == 168: // 192.168.0.0/16
            return true
        default:
            return false
        }
    }

    // 3. 处理IPv6
    if ip6 := ip.To16(); ip6 != nil {
        // 判断是否为IPv6唯一本地地址 (Unique Local Address, RFC 4193), 前缀为 fd00::/8
        if ip6[0] == 0xfd {
            return true
        }
        // 也可以考虑屏蔽链路本地地址 (fe80::/10) 等，根据你的安全需求决定
        // if ip6[0] == 0xfe && (ip6[1]&0xc0) == 0x80 {
        //     return true
        // }
    }

    return false
}

注意事项与心得：

• 包含回环地址 ： 127.0.0.1 和 ::1 必须被禁止。攻击者可能利用它来访问服务器本地的敏感服务（如监听 127.0.0.1:9200 的Elasticsearch）。
• IPv6不能忘 ：随着云原生和IPv6的普及，忽略IPv6的防护会留下巨大缺口。 fd00::/8 是IPv6的私有地址段，相当于IPv4的 10.0.0.0/8 。
• 性能考量 ：这个函数逻辑简单，性能开销极小，可以放心在每次请求前调用。

3.2 第一道防线：在DialContext中锁定目标IP

这是防御DNS重绑定和所有基于IP欺骗攻击的最有效、最推荐的方法。其核心思想是：在TCP连接建立之前，我们就解析出目标主机的所有IP，并逐一检查。我们通过自定义 http.Transport 的 DialContext 函数来实现。

package ssrf

import (
    "context"
    "fmt"
    "net"
    "net/http"
    "syscall"
)

// SafeTransport 返回一个配置了SSRF防护的 *http.Transport。
// 方案一：在 DialContext 中解析并过滤IP。
func SafeTransport() *http.Transport {
    // 克隆默认Transport，保留其优秀的连接池等默认配置
    transport := http.DefaultTransport.(*http.Transport).Clone()

    // 自定义拨号器
    dialer := &net.Dialer{}

    // 重写 DialContext 方法
    transport.DialContext = func(ctx context.Context, network, addr string) (net.Conn, error) {
        // addr 的格式是 "host:port"，例如 "example.com:80" 或 "192.168.1.1:8080"
        host, port, err := net.SplitHostPort(addr)
        if err != nil {
            // 如果拆分失败，可能是地址格式不对，直接拒绝
            return nil, fmt.Errorf("invalid address %q: %v", addr, err)
        }

        // 对主机名进行DNS解析，获取所有IP地址（IPv4和IPv6）
        ips, err := net.LookupIP(host)
        if err != nil {
            return nil, fmt.Errorf("failed to resolve host %q: %v", host, err)
        }

        var lastErr error
        // 遍历所有解析到的IP
        for _, ip := range ips {
            // 关键检查：是否为私有IP
            if IsPrivateIP(ip) {
                // 记录日志，但继续尝试其他IP
                // log.Printf("SSRF blocked: host %q resolved to private IP %s", host, ip)
                continue // 跳过这个私有IP，尝试下一个
            }

            // 使用合格的IP重新组装地址
            safeAddr := net.JoinHostPort(ip.String(), port)
            conn, err := dialer.DialContext(ctx, network, safeAddr)
            if err == nil {
                // 成功连接到第一个非私有IP，返回连接
                return conn, nil
            }
            lastErr = err // 记录连接失败的错误
        }

        // 如果所有IP都是内网IP，或者所有非内网IP都无法连接
        if lastErr != nil {
            return nil, fmt.Errorf("all resolved IPs for %q are either private or unreachable, last error: %v", host, lastErr)
        }
        return nil, fmt.Errorf("host %q resolved only to private IP addresses", host)
    }

    return transport
}

// 使用安全的Transport创建Client
func NewSafeClient() *http.Client {
    return &http.Client{
        Transport: SafeTransport(),
    }
}

这个方案的强大之处：

1. 防御DNS重绑定 ：在建立TCP连接的最后一刻（ DialContext ）进行DNS解析和IP检查。即使攻击者DNS的TTL为0，我们这次解析的结果就是最终用于连接的结果，攻击者没有第二次机会“换”成内网IP。
2. 覆盖所有IP格式 ：无论用户输入的是 192.168.1.1 、 0xC0A80101 还是 evil.attacker.com ，最终都会在这里被解析为标准 net.IP 并进行判断，彻底绕过了字符串匹配的局限性。
3. 支持多IP主机 ：如果一个域名解析出多个IP（如CDN），我们会尝试所有非内网IP，直到有一个连接成功，不影响正常服务的可用性。

3.3 更底层的控制：使用Dialer.Control（Go 1.11+）

如果你使用的是Go 1.11或更高版本，还有一个更优雅的方案——使用 net.Dialer.Control 方法。这个方法会在套接字创建之后、连接建立之前被调用，此时我们已经有了一个确定的、解析好的 ip:port 格式的地址。

// SafeTransportWithControl 使用 Dialer.Control 进行防护。
// 此方案更简洁，但要求 Go >= 1.11。
func SafeTransportWithControl() *http.Transport {
    dialer := &net.Dialer{}

    // 设置Control函数
    dialer.Control = func(network, address string, c syscall.RawConn) error {
        // 注意：这里的 address 已经是 `ip:port` 格式，例如 `93.184.216.34:80`
        host, _, err := net.SplitHostPort(address)
        if err != nil {
            return fmt.Errorf("invalid address in Control: %w", err)
        }

        ip := net.ParseIP(host)
        if ip == nil {
            return fmt.Errorf("failed to parse IP from address %q", address)
        }

        if IsPrivateIP(ip) {
            return fmt.Errorf("connection to private IP %s is blocked", ip)
        }
        return nil // 允许连接
    }

    transport := http.DefaultTransport.(*http.Transport).Clone()
    transport.DialContext = dialer.DialContext // 使用我们自定义的Dialer
    return transport
}

方案对比与选型建议：

• 方案一（自定义 DialContext ） ：兼容性更好（所有Go版本），控制力更强（可以遍历多IP），是通用选择。
• 方案二（ Dialer.Control ） ：代码更简洁清晰，逻辑上更“干净”（在连接前一刻检查）。 强烈推荐在满足Go版本要求的情况下使用此方案 。
• 共同优点 ：两者都能完美防御DNS重绑定、IP格式绕过，并且将防护逻辑植入TCP连接层，覆盖了所有基于 http.Client 的请求（包括 http.Get/Post 等快捷函数，只要它们使用了这个自定义的 Transport ）。

4. 加固防线：处理HTTP重定向与额外策略

仅仅锁死TCP连接的目标还不够，我们还需要防范在HTTP协议层发生的“转向”攻击。

4.1 驯服重定向：自定义CheckRedirect

默认的 http.Client 会自动跟随最多10次重定向。我们需要自定义 CheckRedirect 函数，在每次即将跟随重定向前，检查重定向的目标是否安全。

// NewSafeClientWithRedirectCheck 创建一个同时防护重定向的客户端。
func NewSafeClientWithRedirectCheck() *http.Client {
    safeTransport := SafeTransportWithControl() // 或 SafeTransport()

    client := &http.Client{
        Transport: safeTransport,
        // 自定义重定向检查策略
        CheckRedirect: func(req *http.Request, via []*http.Request) error {
            // 1. 限制最大重定向次数，避免循环重定向或过长的重定向链
            if len(via) >= 10 {
                return fmt.Errorf("stopped after 10 redirects")
            }

            // 2. 对于307/308状态码要特别小心！
            // 它们会保持原请求方法（如POST）。如果原请求是提交表单到外网，
            // 重定向到一个内网地址，就可能造成对内网的POST攻击。
            if req.Response != nil {
                switch req.Response.StatusCode {
                case http.StatusTemporaryRedirect, http.StatusPermanentRedirect: // 307, 308
                    // 出于最严格的安全考虑，可以直接禁止跟随307/308重定向
                    return fmt.Errorf("redirects with status %d are not allowed for security reasons", req.Response.StatusCode)
                }
            }

            // 3. 检查重定向目标URL的Host是否为内网
            // 注意：req.URL.Host 可能包含端口号，如 `192.168.1.1:8080`
            host := req.URL.Hostname() // 获取纯主机名，去掉端口
            ips, err := net.LookupIP(host)
            if err != nil {
                return fmt.Errorf("failed to resolve redirect host %q: %v", host, err)
            }

            for _, ip := range ips {
                if IsPrivateIP(ip) {
                    return fmt.Errorf("redirect to private IP %s is blocked", ip)
                }
            }
            // 4. 所有检查通过，允许重定向
            return nil
        },
    }
    return client
}

实操心得：

• 307/308是“危险分子” ：301/302/303重定向在规范中会 将方法改为GET （即使原请求是POST）。但307/308会 保持原方法 。这意味着，如果用户提交了一个POST请求到你的端点，你的服务器处理后再307重定向到一个内网地址，你的客户端就会用POST方法去请求内网，风险极高。对于不受信任的源发起的重定向，直接禁止307/308是最稳妥的。
• 性能注意 ： CheckRedirect 中又进行了一次 net.LookupIP 。虽然安全，但增加了重定向时的延迟。一个优化点是，可以结合 Transport 的防护：如果 Transport 的 DialContext 或 Control 已经确保了连接的目标IP非内网，那么重定向时的DNS解析结果理论上也是安全的。但为了逻辑清晰和防御的层次性，这里保留检查是更严谨的做法。

4.2 实施端口与协议白名单

SSRF不仅可以攻击HTTP服务，还可以攻击Redis、Memcached、数据库等任何基于TCP的服务。虽然Golang的 http.Client 会检查URL scheme（必须是 http 、 https 等），但攻击者可以尝试连接内网的 redis://192.168.1.2:6379 吗？实际上， http.Client 会拒绝非HTTP(S)的scheme。但攻击者可以通过 http://192.168.1.2:6379 这样的形式尝试与Redis通信（Redis协议是明文的，可能返回错误信息，从而暴露服务存在）。

因此，除了IP黑名单（内网），我们还应考虑 端口白名单 。例如，你的应用只应该从外部获取网页和图片，那么你可能只允许访问80和443端口。

// 在 DialContext 或 Control 函数中添加端口检查
func SafeTransportWithPortFilter(allowedPorts map[int]bool) *http.Transport {
    dialer := &net.Dialer{}
    dialer.Control = func(network, address string, c syscall.RawConn) error {
        host, portStr, err := net.SplitHostPort(address)
        if err != nil {
            return err
        }
        port, err := net.LookupPort("tcp", portStr) // 将服务名（如"http"）或字符串端口转为数字
        if err != nil {
            return err
        }

        // 检查端口是否在白名单
        if !allowedPorts[port] {
            return fmt.Errorf("port %d is not allowed", port)
        }

        ip := net.ParseIP(host)
        if IsPrivateIP(ip) {
            return fmt.Errorf("connection to private IP %s is blocked", ip)
        }
        return nil
    }

    transport := http.DefaultTransport.(*http.Transport).Clone()
    transport.DialContext = dialer.DialContext
    return transport
}

// 使用示例：只允许80和443端口
client := &http.Client{
    Transport: SafeTransportWithPortFilter(map[int]bool{80: true, 443: true}),
}

4.3 错误信息处理——安全的重要一环

这是很多开发者忽略的“社会工程学”漏洞。当你的防护逻辑拒绝了一个请求时，返回给用户的错误信息至关重要。

绝对不要这样做：

if IsPrivateIP(targetIP) {
    w.WriteHeader(http.StatusBadRequest)
    w.Write([]byte(fmt.Sprintf("Access to private IP %s is forbidden.", targetIP))) // 信息泄露！
}

这等于告诉攻击者：“你猜的 192.168.1.1 这个IP确实存在，而且我识别出它是内网IP了。” 这有助于攻击者调整攻击策略。

应该这样做：

// 在业务处理函数中
safeClient := NewSafeClientWithRedirectCheck()
resp, err := safeClient.Get(userProvidedURL)
if err != nil {
    // 统一、模糊的错误信息
    log.Printf("WARN: SSRF check failed for URL %q: %v", userProvidedURL, err) // 详细错误记日志
    http.Error(w, "Failed to fetch the requested resource. Please check the URL and try again.", http.StatusBadRequest)
    return
}
// ... 处理成功的响应

在 Transport 或 Dialer.Control 中返回的错误，最终会体现在 http.Client.Do() 返回的 err 里。在业务层，我们只需记录详细的错误日志供自己排查，而给用户返回一个通用的、友好的错误提示即可。

5. 实战集成与常见问题排查

5.1 在Web框架中全局集成安全客户端

以最常用的Gin框架为例，我们可以在初始化阶段创建这个安全的客户端，并通过依赖注入或全局变量的方式供所有处理器使用。

package main

import (
    "yourproject/ssrf" // 假设上面的防护代码放在这个包
    "github.com/gin-gonic/gin"
    "io"
    "net/http"
)

var safeHTTPClient *http.Client

func init() {
    // 初始化全局的安全HTTP客户端
    safeHTTPClient = ssrf.NewSafeClientWithRedirectCheck()
    // 可以进一步配置超时等
    safeHTTPClient.Timeout = 30 * time.Second
}

func main() {
    r := gin.Default()
    r.POST("/fetch", handleFetchURL)
    r.Run(":8080")
}

func handleFetchURL(c *gin.Context) {
    url := c.PostForm("url")
    if url == "" {
        c.JSON(http.StatusBadRequest, gin.H{"error": "URL is required"})
        return
    }

    // 使用安全客户端发起请求
    resp, err := safeHTTPClient.Get(url)
    if err != nil {
        // 记录具体错误，返回模糊信息
        c.JSON(http.StatusBadRequest, gin.H{"error": "Unable to process the provided URL"})
        return
    }
    defer resp.Body.Close()

    // 这里可以限制读取的响应体大小，防止DoS
    limitedReader := io.LimitReader(resp.Body, 10*1024*1024) // 限制10MB
    data, err := io.ReadAll(limitedReader)
    if err != nil {
        c.JSON(http.StatusInternalServerError, gin.H{"error": "Failed to read response"})
        return
    }

    // 根据业务逻辑处理 data...
    c.Data(resp.StatusCode, resp.Header.Get("Content-Type"), data)
}

5.2 常见问题与排查技巧实录

即使实现了上述防护，在实际部署中你仍可能遇到一些意想不到的问题。下面是我在实践中总结的“避坑指南”。

问题1：服务请求某些合法的公有云元数据服务（如AWS的169.254.169.254）被阻断。

• 原因 ： 169.254.169.254 是链路本地地址（Link-local），属于 169.254.0.0/16 网段。我们的 IsPrivateIP 函数没有包含这个网段，但一些云厂商用它来提供实例元数据。攻击者确实可以利用这个地址进行SSRF攻击（著名的云元数据服务SSRF漏洞）。
• 解决方案 ：这是一个策略选择。
  • 方案A（默认安全） ：在 IsPrivateIP 中加入对该网段的判断并阻止。如果你的应用不需要访问元数据服务，这是最安全的。

  // 在IsPrivateIP的IPv4判断部分添加
  case ip4[0] == 169 && ip4[1] == 254: // 169.254.0.0/16
      return true
  

  • 方案B（需要访问） ：不将其视为私有IP，但 必须 在业务层通过 白名单域名/IP 进行严格控制。例如，只允许访问一个固定的、已知的元数据服务域名，而不是允许所有 169.254.0.0/16 的访问。

问题2：应用需要调用内部的其他微服务（内网调用），也被安全客户端阻止了。

• 原因 ：防护策略是无差别攻击，所有对内网IP的请求都被禁止了。
• 解决方案 ：你需要区分“用户可控的、指向外部的请求”和“程序内部发起的、可信的内部服务调用”。
  • 关键设计 ：不要使用同一个 http.Client 。创建两个客户端：
    1. 安全客户端 ：用于处理 用户提供的、不可信的URL 。使用我们上面实现的、带有严格防护的 Transport 。
    2. 内部客户端 ：用于服务间通信。使用默认的 http.Client 或一个配置了服务发现、负载均衡的客户端（如连接Consul）。这个客户端不需要SSRF防护，因为它访问的是你信任的内部环境。
  • 代码隔离 ：在代码结构上清晰区分这两种调用场景，避免误用。

问题3：性能下降，尤其是频繁请求新域名时感觉变慢。

• 原因 ：我们的 DialContext 实现中对每个主机名都进行了 net.LookupIP 。虽然Go的解析器有并发能力，但频繁的DNS查询仍会带来开销，并且没有利用DNS缓存。
• 排查与优化 ：
  1. 启用Go内置的DNS缓存 ：Go标准库本身没有全局DNS缓存。可以考虑使用第三方包，如 github.com/patrickmn/go-cache ，在应用层实现一个简单的DNS缓存。在 DialContext 中，先查缓存，缓存未命中再调用 net.LookupIP ，并将结果存入缓存（注意设置合理的TTL，可以比DNS记录的TTL短一些）。
  2. 调整 http.Transport 参数 ： MaxIdleConns 、 MaxIdleConnsPerHost 等参数可以显著影响高并发下的性能。确保连接池配置合理。
  3. 监控与日志 ：为安全客户端的请求添加耗时日志，确认瓶颈是否真的在DNS解析。

问题4：如何测试防护是否生效？

你不能总等到被攻击了才知道防护没用。需要建立测试用例。

• 单元测试 ：为 IsPrivateIP 函数编写全面的测试，覆盖各种IPv4/IPv6格式、边界情况。
• 集成测试 ：搭建一个简单的测试服务器，模拟内网服务（监听 127.0.0.1:9999 ）。然后使用你的安全客户端去请求 http://127.0.0.1:9999 、 http://localhost:9999 、 http://0x7f000001:9999 （127.0.0.1的十六进制整数）、 http://attacker-controlled-domain-that-resolves-to-127.0.0.1 等，断言这些请求都应该失败。
• 重定向测试 ：部署一个返回 302 跳转到内网地址的公网测试端点，验证你的 CheckRedirect 逻辑能正确拦截。

安全防护是一个持续的过程，没有一劳永逸的方案。将上述策略集成到你的Golang项目中，能极大地提升服务对SSRF攻击的免疫力。记住，关键是将防护逻辑下沉到网络连接层（ Transport ），并结合应用层的逻辑（如错误处理、端口过滤），构建一个纵深防御体系。