gost：一条命令搭出任意隧道

一个统一的心智模型

gost 的参数看着杂，其实只有四个角色，而且是对称的：

        入口侧                              出口侧
   ┌──────────────────┐            ┌──────────────────┐
   │ Listener  收连接 │            │ Dialer    建连接 │
   │ Handler   懂协议 │  ────────► │ Connector 懂协议 │
   └──────────────────┘            └──────────────────┘
        由 -L 定义                      由 -F 定义

• Listener / Dialer 管传输：裸 TCP、TLS、WebSocket、gRPC、QUIC、KCP……
• Handler / Connector 管协议：HTTP、SOCKS5、Relay、SS……
• -L 起一个服务（我在这儿收），-F 指定下一跳（我从那儿出去）
• 多个 -F 串起来就是转发链（chain），按参数出现顺序逐跳走

理解这四个角色之后，gost 的能力就变成一道组合题：任意协议 × 任意传输 × 任意跳数。

起一个代理服务：-L

# HTTP 代理
gost -L http://:8080

# 两个服务同时起：HTTP 8080 + SOCKS5 1080
gost -L http://:8080 -L socks5://:1080

# 省略协议名 = auto，同一个端口自动识别 HTTP / SOCKS4 / SOCKS5
gost -L :8080

最后那个 auto 很实用：一个端口同时伺候三种协议，相当于 Clash 里的 mixed-port， 客户端配 HTTP 还是 SOCKS5 都能用。

认证信息写在 URL 的 userinfo 部分：

gost -L "http://user:pass@:8080"

串成转发链：-F

# 本地 8080 收，经 192.168.1.1:8080 这个上游代理出去
gost -L http://:8080 -F http://192.168.1.1:8080

# 两跳：先 HTTP 代理，再 SOCKS5 代理，最终从 192.168.1.2 出网
gost -L :8080 -F http://192.168.1.1:8080 -F socks5://192.168.1.2:1080

-F 的顺序就是流量经过的顺序，最后一个 -F 是真正的出口。这是 ssh 隧道做不到的： ssh -J 只能串 SSH，gost 能把不同协议混在一条链上。

端口转发

语法是在监听地址后面直接跟目标：协议://:本地端口/目标:端口

# TCP：本地 8080 → 192.168.1.1:80
gost -L tcp://:8080/192.168.1.1:80

# UDP：本地 10053 → 192.168.1.1:53（DNS 转发）
gost -L udp://:10053/192.168.1.1:53

# 经转发链做端口转发
gost -L=tcp://:8080/192.168.1.1:80 -F socks5://192.168.1.2:1080

对照 SSH：gost -L tcp://:8080/目标:80 ≈ ssh -L 8080:目标:80， 但 gost 这条多了 UDP 支持——这是 SSH 端口转发的硬缺口。

反向转发：内网穿透

rtcp / rudp 把监听端口开在链路对端，等于 ssh -R，但不需要对端开 GatewayPorts：

# 在内网机器上执行：把本机 22 端口暴露到 192.168.1.2 的 2222 上
gost -L=rtcp://:2222/:22 -F socks5://192.168.1.2:1080

流量方向：外面的人连 192.168.1.2:2222 → 经隧道回到内网机器 → 落到它的 :22。

换传输层

同一个协议可以跑在不同传输之上，这是 gost 最有价值的能力之一。写法是 协议+传输：

写法	含义	适用
http://	裸 HTTP	内网，无需伪装
http+tls:// / https://	HTTP over TLS	需要加密
relay+wss://	Relay over WebSocket over TLS	要穿过只放 HTTP(S) 的网络
relay+mwss://	同上，多路复用	要经 CDN 前置（复用能显著降低握手开销）
http2:// / grpc://	HTTP/2 / gRPC	长连接多路复用，特征自然
kcp:// / quic://	UDP 基础上的可靠传输	高丢包链路

选择依据很实际：看你的网络放什么过去。只放 443 的环境用 wss； 需要经 CDN 就得用 WebSocket 系（CDN 只代理 HTTP 语义的流量）； 链路丢包严重才考虑 kcp/quic。

分流：bypass

不是所有流量都该走隧道。bypass 让指定目标直连：

# 这些域名不走上游链路，直接本地出网
gost -L :8080 -F "socks5://1.2.3.4:1080?bypass=*.cn,*.internal,10.0.0.0/8"

# 反过来：只有匹配的才绕过（~ 前缀表示取反）
gost -L :8080 -F "socks5://1.2.3.4:1080?bypass=~*.example.com"

企业内网场景里这个几乎必配：内网域名和私网段必须直连， 否则请求绕一圈出去再回来，慢且经常失败——和上一节 NO_PROXY 是同一个道理， 只是这次由代理自己判断。

一个真实的服务端形态

社区里流传较广的自建方案（见 haoel 的科学上网笔记） 大致是这个形状：

# 服务端：HTTP/2 over TLS，用真实证书，带主动探测抵抗
docker run -d --name gost --restart=always --net=host \
  -v /etc/letsencrypt:/etc/letsencrypt:ro \
  gogost/gost \
  -L "http2://user:pass@:443?cert=/etc/letsencrypt/live/example.com/fullchain.pem\
&key=/etc/letsencrypt/live/example.com/privkey.pem&probe_resist=file:/var/www/index.html"

# 客户端：本地 mixed 端口，转发到服务端
gost -L :1080 -F "http2://user:pass@example.com:443"

三个要点：

• 用真实域名和真实证书（Let's Encrypt + certbot 自动续期），别用自签
• probe_resist 决定"别人直接用浏览器访问这个端口时看到什么"—— 返回一个正常网页比返回错误更不引人注意，这属于下一节流量特征的话题
• 服务端顺手把 BBR 打开（net.ipv4.tcp_congestion_control=bbr）， 长肥链路上的收益很直接（L0 讲过原因）

检查点

检查点单选

gost -L :8080 -F http://A:8080 -F socks5://B:1080 这条命令，流量最终从哪台机器出网？

• AB —— 最后一个 -F 是真正的出口
• BA —— 第一个 -F 优先
• C本机 —— -F 只是备用
• D随机选一个做负载均衡

提交

检查点单选

需要把内网一台机器的 UDP 服务（比如 DNS）转发给外部访问，长期挂着。用什么？

• Agost 的 rudp 反向转发
• Bssh -R 远程转发
• Cssh -D 动态转发
• Dssh -L 本地转发

提交

检查点单选

在企业内网部署 gost 代理，为什么几乎一定要配 bypass？

• A内网域名与私网段必须直连，绕出去再回来会变慢甚至失败
• B为了提升加密强度
• C为了绕过认证
• D为了支持 UDP

提交

这节课的落点

• 四个角色：Listener/Dialer 管传输，Handler/Connector 管协议；-L 起服务，-F 指下一跳
• -L :8080 的 auto 模式让一个端口同时支持 HTTP 与 SOCKS5
• 多个 -F 按顺序串成转发链，最后一个是出口
• 端口转发 -L tcp://:8080/目标:80，反向 rtcp / rudp 做内网穿透
• gost 相对 ssh 的三个优势：UDP 转发、长期穿透、多协议混合链 + 传输层可换
• 传输层按"网络放什么过去"选：只放 443 用 wss，经 CDN 必须 WebSocket 系
• bypass 必配，内网域名与私网段一律直连
• 公网上的代理一定要加认证，否则很快会被扫到滥用