AGENT

服务器

2026/05/01 4 min read AGENT 服务器
  • jd-lavm-beijing -> 111.228.6.224
    • jd-lavm-yp7m9xmd5l -> 111.228.6.224
    • server-170 -> 170.106.179.226
    • server-124 -> 124.220.233.126
    • server-171 -> 8.222.214.171

你这段内容到底在干嘛？（逐段翻译）

1. 最开头的关键结论

plaintext

不能直接导进 sub2api 的代理池。
原因：你给的是 SSH 服务器，不是代理节点

→ 你给的那 4 个 IP 只是普通服务器，不能直接当代理用。

→ 必须先在上面装 SOCKS5 代理软件，才能给 sub2api 用。

2. 你让我做的事

plaintext

帮你把 170 上的一个 socks5 出口配出来，再导入 sub2api。

→ 我正在帮你在 170.106.179.226 这台机器上部署 SOCKS5 代理

3. 我正在做的动作

plaintext

看脚本 → 找部署方式 → 查 sub2api 导入代理的接口 → 准备一键部署
  • 查 setup-socks5-proxy.sh 代理部署脚本
  • 查 sub2api 怎么导入代理
  • 查 /api/v1/admin/proxies/data 管理接口
  • 准备一键部署 + 自动接入 sub2api

4. 最后一句

plaintext

准备复用现成脚本，在 170 上启动 SOCKS5 并写入 sub2api

→ 马上就要部署完成了

我给你用最简单、最接地气讲透，为啥：

服务器公网 IP 是 170.106.179.226

但 socks5 反而用 172.18.0.1:1080

1. 先搞懂两个 IP 是什么

  • 170.106.179.226

    这是服务器公网 IP，外网任何人都能访问。

  • 172.18.0.1

    这是 Docker 内网网桥网关 IP

    不是公网 IP，是机器内部虚拟局域网地址。

2. 为什么不监听公网 170.106.179.226:1080？

反而监听 172.18.0.1:1080？

原因一：sub2api 跑在 Docker 容器里

sub2api 是 Docker 部署的，它在：

sub2api-network 这个虚拟网桥里

容器内部访问宿主机，网关就是：

172.18.0.1

👉 容器不能直接连公网 IP 绕一圈，只能走内网网关最快、最稳。

原因二：不走公网绕路，不走防火墙

如果监听公网 170.106.179.226:1080：

  • 要过服务器防火墙
  • 要过云厂商安全组
  • 还要走公网链路，延迟高、容易被封、被扫端口

监听 172.18.0.1:1080：

  • 纯内网流转，不出公网
  • 不走外网、不暴露端口到公网
  • 防火墙根本拦不到
  • 速度最快、最隐蔽、不会被端口扫描

原因三：安全

公网开 1080 端口 = 全世界都能扫到、暴力破解、薅你代理流量。

只监听 172.18.0.1 = 只有本机 Docker 内部能用，外人连不上。

3. 工作链路一目了然

plaintext

sub2api容器
   ↓
Docker内网 172.18.0.0/16
   ↓
宿主机 172.18.0.1:1080 （Socks5）
   ↓
宿主机公网 170.106.179.226 出网访问AI

流量是：

容器 → 内网网关 socks5 → 宿主机公网 IP 出去

4. 总结一句话

  • 170.106.179.226 是对外落地 IP
  • 172.18.0.1:1080 是给 Docker 里 sub2api 专用的内网代理入口

好处：

✅ 不暴露 1080 到公网

✅ 不走外网绕路

✅ Docker 容器直连最快

✅ 安全防扫、防盗用

✅ 不受防火墙 / 安全组限制

补充：那 sub2api 怎么识别这个代理？

在 sub2api 里添加代理时填：

  • 地址：172.18.0.1
  • 端口：1080

sub2api 在 Docker 网桥里，本来就能直接访问 172.18.0.1，通的很稳。