Gost v3中转

发表于 2025-01-14 更新于 2025-01-17 阅读次数：本文字数： 2.5k 阅读时长 ≈ 3 分钟

不想使用x-ui的任意门，所以使用了更加专业的Gost 来中转

Gost GitHub

Gost官方文档

下载

二进制文件

https://github.com/go-gost/gost/releases

找到好版本，然后用 wget

解压

tar -zxvf gost_3.0.0_linux_amd64.tar.gz

无法运行记得给权限

使用

方式1

中转机：./gost -L tcp://:中转机入站端口 -F relay+tls://落地机IP:落地机入站端口

落地机：./gost -L relay+tls://:落地机入站端口/:节点端口

方式2

1.1.1.1 为落地 IP

中转机：./gost -L tcp://:9527/1.1.1.1:80 -F relay+tls://1.1.1.1:8443

落地机：./gost -L relay+tls://:8443

可以把 IP 换为网址

##后台运行，并且把日志写入到 gost.log，名称可自定义
nohup 运行指令 > gost.log 2>&1 &

##丢弃日志，推荐测试完成后丢弃，这个日志会变大的
nohup 运行指令 > /dev/null 2>&1 &

##中转转发UDP
./gost -L tcp://:9527  -L udp://:9527 -F relay+tls://1.1.1.1:8443

在落地机搭建好节点，把IP和端口改成中转机的 IP 和转发端口就行了

查询后台正在运行

ps aux | grep gost | grep -v grep

删除后台
kill pid

区别（GPT的回答）

下面分别对两种配置方式进行详细说明，并探讨它们在使用场景与配置便捷性方面的差异。

方式 1

中转机 (Relay Server):

1	./gost -L tcp://:9527 -F relay+tls://1.1.1.1:8443

落地机 (Target Server):

1	./gost -L relay+tls://:8443/:80

中转机监听本地 TCP 端口 9527，并通过 relay+tls 协议把流量转发到落地机的 1.1.1.1:8443。
落地机在 8443 端口上监听 relay+tls 流量，并最终将流量转发到本地 80 端口。

在这种布局下：
• 中转机对外暴露的 TCP 端口是 9527，落地机对外暴露的 relay+tls 端口是 8443。
• 客户端连接到中转机的 9527 端口时，中转机会将流量加密并转发到落地机的 8443，然后落地机解密后将流量转发到本机 80 端口。
• 这种方式较为直观：中转机本身只做简单的 TCP 监听与加密转发，不指定最终的后端端口（由落地机自己确定 80）。

配置方式 2

中转机 (Relay Server):

1	./gost -L tcp://:9527/1.1.1.1:80 -F relay+tls://1.1.1.1:8443

落地机 (Target Server):

1	./gost -L relay+tls://:8443

中转机监听本地 TCP 端口 9527，并且在本条指令中已经将后端 IP:Port 显式指定为 1.1.1.1:80，然后再使用 relay+tls 协议将流量加密发送到 1.1.1.1:8443。
落地机只需要对外监听 relay+tls://:8443，并把解密后的流量直接送到 1.1.1.1:80（因为在中转机命令里已经填写了最终地址）。

在这种布局下：
• 中转机直接定义了后端服务地址 “1.1.1.1:80”，落地机只负责监听加密端口 8443 并把流量转发到对应的本地端口（通常是 1.1.1.1:80，若落地机是同一台机器，IP 可理解为本机 IP）。
• 好处是中转机的一条命令就能控制最终流向的地址，不需要在落地机处指定后端端口。缺点是落地机配置更为简化，但中转机对后端 IP/端口的依赖更强。

两种方式的对比与选择

配置灵活度：
- 方式 1 更加模块化：中转机只做加密转发，落地机决定 80 端口或其他端口。后期若要修改后端端口，只需改动落地机的配置即可。
- 方式 2 更加集中：中转机一条命令中明确指定了 “1.1.1.1:80”，落地机无需指定后端端口，配置更简单，但导致中转机和落地机耦合更紧密。
可维护性：
- 如果你需要经常在落地机上变更端口或部署新的服务，方式 1 更符合“解耦”思路。
- 如果整个维护都由中转机负责，而落地机始终只跑一个服务（例如指定的 1.1.1.1:80），方式 2 则更方便。
安全性：
- 两种方式的加密协议都是 relay+tls，本质安全性相似，主要取决于证书配置与网络环境。
- 实际安全需求（例如是否需要验证证书、双向 TLS 等）可在具体命令或配置文件中进一步完善。
性能与负载：
- 方式 1 与方式 2 的性能基本差异不大，因为核心逻辑都是中转机加密转发、落地机解密并转发到 80 端口。
- 若有复杂负载或需要负载均衡，推荐进一步探索 GOST 的多路复用或其它模式。