WebSocket代理双连接场景下Header处理最佳实践及实现模式疑问

我来帮你拆解下你遇到的这几个问题，结合两种实现模式的特点来分析：

一、双连接模式（Approach 2）的Header处理方案 #

1. 哪些Header需要转发/过滤 #

首先要明确HTTP头分为两类：Hop-by-Hop头和End-to-End头：

• Hop-by-Hop头：只在当前连接有效，必须由代理过滤掉，不能转发给目标服务器，包括：Connection、Keep-Alive、Proxy-Authenticate、Proxy-Authorization、TE、Trailers、Transfer-Encoding、Upgrade。
• End-to-End头：需要完整转发给目标服务器，比如Cookie、Authorization、User-Agent、X-Forwarded-For这类业务或客户端标识相关的头。

另外要注意：WebSocket握手的核心头（比如Sec-WebSocket-Key、Sec-WebSocket-Version、Sec-WebSocket-Protocol）会由coder/websocket库自动处理，你不需要手动复制这些，避免干扰正常握手流程。

2. 具体实现代码示例 #

你可以在创建目标服务器连接时，手动构建并设置请求头：

import "strings"
import "net"
import "errors"

func handleWebSocketConnection(w http.ResponseWriter, r *http.Request) {
    clientConn, err := websocket.Accept(w, r, nil)
    if err != nil {
        log.Printf("Failed to accept WebSocket connection: %v", err)
        return
    }
    defer clientConn.Close(200, "Client disconnected")

    tlsConfig := &tls.Config{
        InsecureSkipVerify: false,
        // ... 证书配置
    }
    httpClient := &http.Client{
        Transport: &http.Transport{
            TLSClientConfig: tlsConfig,
        },
    }

    // 构建目标请求头：过滤Hop-by-Hop头，保留End-to-End头
    targetHeader := make(http.Header)
    for key, values := range r.Header {
        keyLower := strings.ToLower(key)
        // 跳过Hop-by-Hop头
        if keyLower == "connection" || keyLower == "keep-alive" || 
           keyLower == "proxy-authenticate" || keyLower == "proxy-authorization" ||
           keyLower == "te" || keyLower == "trailers" || keyLower == "transfer-encoding" ||
           keyLower == "upgrade" {
            continue
        }
        // 复制其他头的所有值
        targetHeader[key] = append(targetHeader[key], values...)
    }

    // 添加代理标识头（可选，符合HTTP代理规范）
    targetHeader.Add("Via", "1.1 your-websocket-proxy")
    // 添加X-Forwarded-For记录客户端真实IP
    if clientIP, _, err := net.SplitHostPort(r.RemoteAddr); err == nil {
        targetHeader.Add("X-Forwarded-For", clientIP)
    }

    // 建立到目标服务器的WebSocket连接，传入处理后的头
    targetConn, _, err := websocket.Dial(r.Context(), "wss://example.com", &websocket.DialOptions{
        HTTPClient: httpClient,
        Header:     targetHeader,
    })
    if err != nil {
        log.Printf("Failed to connect to target server via TLS: %v", err)
        return
    }
    defer targetConn.Close(200, "Target disconnected")

    // 双向转发数据
    go func() {
        _, err := io.Copy(clientConn.UnderlyingConn(), targetConn.UnderlyingConn())
        if err != nil && !errors.Is(err, io.EOF) {
            log.Printf("Error copying from target to client: %v", err)
        }
    }()
    go func() {
        _, err := io.Copy(targetConn.UnderlyingConn(), clientConn.UnderlyingConn())
        if err != nil && !errors.Is(err, io.EOF) {
            log.Printf("Error copying from client to target: %v", err)
        }
    }()

    // 等待任一连接关闭
    select {}
}

3. 最佳实践总结 #

• 严格过滤Hop-by-Hop头：避免这些头干扰目标服务器的握手逻辑
• 保留原始End-to-End头：除非业务需要（比如添加IP记录），不要随意修改或删除客户端的业务头
• 交给库处理握手核心头：不要手动干预Sec-WebSocket-*系列头，避免握手失败
• 添加代理标识：可选但推荐，通过Via头标识代理节点，便于排查问题
• 测试边界场景：比如客户端带Cookie、认证令牌的请求，确保头转发后业务逻辑正常

二、WebSocket代理的两种实现模式区别 #

两种方案都属于WebSocket代理，但适用场景完全不同：

1. 直通转发模式（Approach 1） #

这种模式相当于TCP层的透明代理，代理只是把客户端的TCP连接直接转发给目标服务器，WebSocket握手和后续的数据传输完全透传。

• 优点：性能极高，不需要处理WebSocket的应用层细节，不需要终止SSL（如果是WSS的话，代理只是转发加密流量）
• 缺点：无法修改或过滤WebSocket消息，无法做业务层面的鉴权、日志，必须依赖目标服务器处理握手逻辑
• 典型场景：反向代理（比如Nginx的WebSocket代理）、简单的流量转发需求

2. 双连接应用层代理（Approach 2） #

这种模式下，代理同时作为客户端的WebSocket服务端和目标服务器的WebSocket客户端，分别建立连接并中转数据。

• 优点：可以在代理层实现消息过滤、鉴权、日志、流量控制等业务逻辑，支持SSL终止（代理可以解密客户端流量，再加密发送给目标服务器）
• 缺点：性能略低（需要处理两次WebSocket握手，中转数据时多一层拷贝），需要手动处理头转发等细节
• 典型场景：需要业务干预的代理（比如企业内部的WebSocket网关、需要鉴权的代理）

总结：日常提到的“WebSocket代理”没有绝对的标准定义，要看具体场景。如果是通用的反向代理，大多是类似Approach1的直通模式；如果是需要做业务处理的网关，就是Approach2的双连接模式。

备注：内容来源于stack exchange，提问作者ray an