Shus's blog
链式代理
Shus
  2026-05-10 14:41:25   2026-05-10 16:53:57

链式代理

这是什么东西

  • 链式代理是指客户端请求不直接到达目标服务器，而是依次经过多个代理节点。每一跳只知道上一跳和下一跳，最终由最后一个代理节点作为出口访问目标服务器。

简单来说就是: Host PC -> Proxy Server 1 -> Proxy Server 2 -> Proxy Server 3 -> Target

部署需求

这里举例用了两个VPS，VPS A和VPS B，然后出口节点作为三级代理（出口），一级代理自己选一个回国优化的NAT/VPS或者用CF优选节点

软件：

  • trojan-go
  • sing-box
  • nginx
  • certbot

开始部署（二级代理）

certbot

1
sudo certbot certonly -d your_domain.com -d www.your_domain.com -d proxy.your_domain.com  --expand
  • 选standalone然后记得放开80端口
    这一步的目的是申请证书

nginx

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
    worker_connections 1024;
}

# ----------------------------------------------------
# L4 层：统一接收公网 443 TCP 流量，并转发到本机 8443 的 HTTP TLS 层
# ----------------------------------------------------
stream {
    map $ssl_preread_server_name $backend_name {
        proxy.your_domain.com    nginx_ssl_layer; 
        your_domain.com           nginx_ssl_layer;
        default                 nginx_ssl_layer; 
    }

    upstream nginx_ssl_layer {
        server 127.0.0.1:8443;  
    }

    server {
        listen 443 reuseport;     
        listen [::]:443 reuseport;
        proxy_pass $backend_name;
        ssl_preread on;           
    }
}

# ----------------------------------------------------
# L7 层：负责 TLS 解密和 域名/IP 路由逻辑
# ----------------------------------------------------
http {
    include /etc/nginx/mime.types;
    default_type application/octet-stream;
    sendfile on;
    server_tokens off;
    
    ...
    
    # -------------------------------------------
    # 场景 G: Trojan-Go 
    # -------------------------------------------
    server {
        listen 8443 ssl;
    	http2 on;
    	server_name proxy.your_domain.com;
        ssl_certificate /path/to/your/fullchain.pem; 		# managed by Certbot
        ssl_certificate_key /path/to/your/privkey.pem; # managed by Certbot


    	location = / {
        	return 404;
    	}

    	
        location /ws {
        	proxy_pass https://127.0.0.1:10443;
        	proxy_http_version 1.1;

        	proxy_set_header Upgrade $http_upgrade;
        	proxy_set_header Connection "upgrade";
        	proxy_set_header Host $host;
        	proxy_set_header X-Real-IP $remote_addr;
        	proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        	proxy_set_header X-Forwarded-Proto $scheme;

	    	proxy_ssl_server_name on; 
	    	proxy_ssl_name proxy.your_domain.com; 
	    	proxy_ssl_verify off;
        	proxy_read_timeout 86400;
    	}
  	}
}

如果一级是 NAT/VPS A 的纯 TCP 转发，则 TLS 主要在 VPS B 的 Nginx/Trojan-Go 上终止
如果一级使用 Cloudflare 橙云，则客户端到 Cloudflare 的 TLS 会先在 Cloudflare 边缘终止，Cloudflare 再以 HTTPS/TLS 回源到 VPS B

proxy_pass https://127.0.0.1:10443 的原因是 Trojan-Go 后端仍然以 TLS + WebSocket 方式监听，所以 Nginx 到 Trojan-Go 之间也要走 HTTPS/TLS。否则 Nginx 用明文 HTTP 转发到一个 TLS 后端，会出现“HTTP request to HTTPS server”一类错误

看不懂没关系，核心链路可以理解为：公网 443 进入 Nginx stream 层，再转到本机 8443 的 Nginx HTTP/TLS 层，最后由 /ws 反代到 127.0.0.1:10443 的 Trojan-Go 后端

trojan-go

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
{
    "run_type": "server",
    "local_addr": "127.0.0.1",
    "local_port": 10443,
    "remote_addr": "127.0.0.1",
    "remote_port": 80,
    "password": [
        "yourpassword"
    ],
    "log_level": 1,
    "ssl": {
        "cert": "/path/to/your/fullchain.pem",
        "key": "/path/to/your/privkey.pem",
        "sni": "proxy.your_domain.com",
        "alpn": [
            "h2",
            "http/1.1"
        ],
        "key_password": "",
        "cipher": "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384",
        "cipher_tls13": "TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384",
        "prefer_server_cipher": true,
        "reuse_session": true,
        "session_ticket": false
    },
    "tcp": {
        "prefer_ipv4": true,
        "no_delay": true,
        "keep_alive": true
    },
    "mux": {
        "enabled": false,
        "concurrency": 8,
        "idle_timeout": 60
    },
    "websocket": {
        "enabled": true,
        "path": "/ws",
        "host": "proxy.your_domain.com"
    },
   "forward_proxy": {
   	"enabled": true,
    	"proxy_addr": "127.0.0.1",
    	"proxy_port": 10808,
    	"username": "",
    	"password": ""
  }
}
  • 解密然后全部丢给10808(sing-box)处理

sing-box

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
{
  "log": {
    "level": "debug",
    "timestamp": true
  },

  "inbounds": [
    {
      "type": "socks",
      "tag": "trojan_forward_in",
      "listen": "127.0.0.1",
      "listen_port": 10808
    }
  ],

  "outbounds": [
    {
      "type": "direct",
      "tag": "direct"
    },
    {
      "type": "socks",
      "tag": "exit_proxy",
      "server": "IP address",
      "server_port": port,
      "version": "5",
      "username": "username",
      "password": "password",
      "network": "tcp"
    }
  ],

  "route": {
    "rules": [
      {
        "inbound": "trojan_forward_in",
        "action": "sniff",
        "timeout": "1s"
      },
      {
	"network": "udp",
	"outbound": "direct"
      }
    ],
    "final": "exit_proxy"
  }
}

  • 注意有些出口节点不支持UDP，所以这里分流就直接让UDP直连，TCP全部通过SOCKS去发给出口节点

    这样做会导致 UDP 流量不经过出口节点，而是直接从 VPS B 出口访问目标。也就是说，DNS、QUIC、游戏 UDP、部分 App UDP 流量可能暴露 VPS B 的 IP，不会显示为出口 IP

三级代理

  • 给二级代理VPS B加入IP白名单

一级代理

一级代理节省成本可以通过CF去作为一级代理，然后用CFST去测速找到最快的优选节点然后配置Host就写优选节点（后面会提到）

  • 如果用的nat就把转发的推到你的proxy.your_domain.com
  • 如果用的VPS如下：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
{
  "log": {
    "level": "debug",
    "timestamp": true
  },
  "inbounds": [
    {
      "type": "direct",
      "tag": "tcp-in-443",
      "listen": "::",
      "listen_port": 443,
      "network": "tcp",
      "override_address": "proxy.your_domain.com",
      "override_port": 443
    }
  ],
  "outbounds": [
    {
      "type": "direct",
      "tag": "direct"
    }
  ],
  "route": {
    "final": "direct"
  }
}

如果一级 VPS A 只是 TCP 前置转发，VPS B 只需要放行来自 VPS A 的 TCP 443。除非你额外转发 UDP，否则不需要放 UDP

代理软件如何填写

  • Host: nat/VPS A IP

    如果使用 Cloudflare：

    • 地址可以填 proxy.your_domain.com，由 DNS 返回 Cloudflare 边缘地址
    • 如果手动使用 CFST 优选 IP，则客户端连接地址填优选 IP，但 SNI 和 WebSocket Host 仍然必须保持 proxy.your_domain.com
    • Cloudflare DNS 记录本身仍然应该指向你的 VPS B 源站 IP，不能把 DNS 记录改成优选 IP

  • Port: nat/VPS A Port

  • SNI: proxy.your_domain.com

  • Password: yourpassword

  • AllowInsecure: No

  • Network: WebSocket

  • WebSocket Host: proxy.your_domain.com

  • Websocket Path: /ws

总结

所以整条链路下来，如果开了橙云用了CF优选或者没有优选只用了CDN优化链路如下：

1
HOST -> CF EDGE/CDN -> VPS B -> Exit Proxy -> Target Server

如果用了NAT或者VPS A：

1
HOST -> NAT(VPS A) -> VPS B -> Exit Proxy -> Target Server

如果直接连接你的VPS B延迟和丢包率都挺低的话不妨直接：

1
HOST ->  VPS B -> Exit Proxy -> Target Server

放在最后

  • 链式不是越长越好，如果直接到VPS B延迟很高，比如直接到VPS A只有200ms, VPS A到VPS B只有200ms，加起来400ms多而直接访问VPS B要600多ms这种情况才需要加多一层前置代理，越长反而越不好

  • 如果不会配置nginx, trojan-go, sing-box这些不妨让AI教你配置，最重要是学习搭建的思想

链式代理
2026/05/10/IT/ProxyChains/
Author
Shus
Published
2026-05-10 14:41
License
 Comments
Comment plugin failed to load
Loading comment plugin