Go解决Websocket跨域CheckOrigin策略

“纵有疾风来，人生不言弃”，这句话送给正在学习Golang的朋友们，也希望在阅读本文《Go解决Websocket跨域CheckOrigin策略》后，能够真的帮助到大家。我也会在后续的文章中，陆续更新Golang相关的技术文章，有好的建议欢迎大家在评论留言，非常感谢！

gorilla/websocket 的 CheckOrigin 必须显式覆盖，因其默认严格校验 Origin 头，仅允许与服务地址完全一致的来源，否则返回 403；它在 WebSocket 握手阶段执行，早于中间件和 handler，CORS 无效；生产环境禁用 return true，需用白名单精确匹配协议、域名、端口。

gorilla/websocket 的 CheckOrigin 为什么必须显式覆盖

默认情况下，gorilla/websocket 的 Upgrader.CheckOrigin 实现会严格校验请求头中的 Origin，只接受与当前服务地址（协议+host+port）完全一致的来源。只要前端页面域名、端口或协议不同——比如 http://localhost:3000 访问 http://localhost:8080，就会直接返回 403 Forbidden，并抛出错误信息：request origin not allowed by Upgrader.CheckOrigin。

这不是服务器没收到请求，而是 Upgrade 阶段被 CheckOrigin 拦在了握手之前，WebSocket 连接根本建立不起来。

• CheckOrigin 是一个函数类型字段：func(*http.Request) bool，必须返回 true 才允许升级
• 它在 HTTP 升级为 WebSocket 的瞬间执行，早于任何 handler 逻辑，中间件也插不上手
• 即使你后面加了 CORS 中间件，对 WebSocket 握手无效——那是 HTTP 层的事，而 WebSocket 握手是独立的 HTTP 请求

生产环境禁用 return true 的三个硬性原因

写死 CheckOrigin: func(r *http.Request) bool { return true } 虽然能快速跑通，但在生产环境等于敞开大门，风险极高：

• 任意网站都能通过 JS 创建 new WebSocket("wss://yoursite.com/ws") 并发起连接，可能被用于 CSRF 或资源滥用
• 如果服务端还依赖 Origin 做租户识别或权限判断（比如多租户 SaaS），这个兜底策略会让所有校验失效
• 当你的 WebSocket 服务需要读取用户 Cookie（即启用了 withCredentials: true）时，浏览器会拒绝连接——因为 Access-Control-Allow-Credentials: true 和宽松的 CheckOrigin 不匹配，安全模型已破坏

安全又实用的 CheckOrigin 白名单实现

真正可控的做法是把可信 Origin 列进白名单，并做精确字符串比对（不推荐正则，易绕过且性能低）：

var upgrader = websocket.Upgrader{
    CheckOrigin: func(r *http.Request) bool {
        origin := r.Header.Get("Origin")
        allowedOrigins := []string{
            "https://example.com",
            "https://admin.example.com",
            "http://localhost:3000",
        }
        for _, o := range allowedOrigins {
            if origin == o {
                return true
            }
        }
        return false
    },
}

• 注意：必须包含协议和端口，https://example.com 和 https://example.com:443 视为不同源
• 不要写 https://*.example.com —— 浏览器不支持通配子域，CheckOrigin 也不解析它
• 如果前端用的是 file:// 协议（如本地双击 HTML 文件），Origin 头为空字符串，需单独判断 origin == ""

GoTTY 场景下用 --ws-origin 替代手写逻辑

如果你用的是 GoTTY（而非自己写的 WebSocket 服务），它已经封装好了 Origin 控制，直接用内置参数更稳妥：

• 开发调试：用 gotty --ws-origin '.*' bash，但仅限本地
• 线上部署：明确指定，例如 gotty --ws-origin '^https?://myapp\.company\.com$' bash
• 多个域名：用括号分组，如 --ws-origin '^https?://(myapp\.company\.com|staging\.myapp\.company\.com)$'

GoTTY 内部也是编译正则后调用 regexp.MatchString，但它的 WSOrigin 字段控制粒度比手写 CheckOrigin 更集中，且避免了在自定义代码里重复造轮子。真正容易被忽略的是：正则中的点号 . 必须转义为 \.，否则 example.com 会被 exampleXcom 匹配到。

以上就是《Go解决Websocket跨域CheckOrigin策略》的详细内容，更多关于的资料请关注golang学习网公众号！