📚 目录

• 前言

• 为什么需要 Stream（L4）透传

• 最终推荐的透传配置

• 为什么 http{} 必须禁用

• Docker host 模式的隐藏坑

• 常见错误与解决方案

• 如何验证透传成功

• 性能说明：透传不等于加速

• 总结

• SEO 关键词

前言

在跨境访问、内网穿透、反向代理等场景中，我们经常需要让一台 VPS 作为“入口”，把所有 HTTP/HTTPS 流量透传到内网服务器（例如 iStoreOS + NPM）。 为了保证 HTTPS 正常工作，必须做到：

• 不终止 TLS

• 不破坏 SNI

• 不解析 HTTP

• 不处理证书

这就需要使用 Nginx/OpenResty 的 stream 模块（L4 层 TCP 透传）。

为什么需要 Stream（L4）透传

普通的 http{} 反代属于 L7 层，会：

• 解析 HTTP

• 终止 TLS

• 破坏 SNI

• 需要证书

这会导致：

• 内网 NPM 无法识别域名

• HTTPS 握手失败

• 证书链断裂

而 stream{} 是 L4 层 TCP 代理：

• 不解析 HTTP

• 不终止 TLS

• 不需要证书

• 完整保留 SNI

• 完整透传 HTTPS

这是跨境 + 内网穿透场景下的唯一正确方式。

最终推荐的透传配置

你的 nginx.conf 最终应该是最简洁的版本：

nginx

events {
    worker_connections 1024;
}

stream {
    server {
        listen 80;
        proxy_pass 内网服务器:80;
    }

    server {
        listen 443;
        proxy_pass 内网服务器:443;
    }
}

说明：

• 内网服务器 为 WireGuard 内网地址（已隐藏）

• VPS 不做任何证书处理

• 所有 HTTPS 由内网 NPM 处理

为什么 http{} 必须禁用

你遇到的最大坑就是：

• http{} 自动监听 80/443

• WAF 自动生成 HTTPS server

• include conf.d/*.conf 自动加载 server{}

• 导致 stream{} 抢不到端口

• 报错：bind() failed: address already in use

即使你没有写 server{}， 面板会自动生成 HTTPS 配置，并且证书是 data: → 直接报错。

所以：

• http{} 必须完全禁用

• 80/443 只能由 stream{} 监听

Docker host 模式的隐藏坑

你遇到的第二大坑：

• 宿主机查不到端口占用

• 但 OpenResty 报端口被占用

• 原因是：OpenResty 自己的 http{} 和 stream{} 在抢端口

这是 host 模式下最常见的误判。

解决方式：

• 禁用 http{}

• 只保留 stream{}

常见错误与解决方案

如何验证透传成功

在 VPS 上执行：

bash

curl -I https://你的域名 --resolve 你的域名:443:内网服务器

如果返回 200/301/302：

• WireGuard 正常

• stream 透传正常

• 内网 NPM 正常

• 证书正常

这就是最终成功的标志。

性能说明：透传不等于加速

你测试后发现：

• stream 透传不会显著提升性能

• 性能瓶颈在内网服务器本身

• WireGuard 的连续性远优于 FRP

• 但性能主要取决于：

  • 内网服务器 CPU

  • IO 性能

  • 应用本身性能

  • 跨境 RTT

所以：

stream 透传解决的是“正确性”，不是“性能”。

总结

OpenResty/Nginx 的 stream 模块是实现 HTTPS 透传的最佳方式。 它能够：

• 保留 SNI

• 不终止 TLS

• 不需要证书

• 不解析 HTTP

• 完整透传到内网 NPM

在跨境访问、内网穿透、WireGuard 隧道等场景中， stream 透传是唯一能保证 HTTPS 正常工作的方式。

最终最佳实践：

• VPS 只运行 OpenResty stream

• http{} 完全禁用

• 80/443 只由 stream{} 监听

• 内网 NPM 负责所有证书和反代

• WireGuard 提供稳定的 L3 隧道

这是一个企业级、稳定、可扩展的架构。