🎯 一句话总结：如果一台 VPS 的网络环境不适合访问某个服务，可以先用 Tailscale 把它和另一台云端主机连成私有网络，再让 3X-UI 通过 SOCKS5 出站把指定域名的请求交给远端出口处理。本文只讲组网、路由和验证，不保证任何特定服务一定可用。

Tailscale 与 VPS 网络出口架构

📌 这套方案解决什么问题

本文参考公开教程中的思路，重组为一条可以逐步检查的配置流程：

本地 VPS
  ↓ Tailscale 私有网络
云端主机上的 SOCKS5
  ↓ 3X-UI 出站与路由
指定域名使用远端出口

它适合这样的场景：你已经有一台运行 3X-UI 的 VPS，另有一台可以运行代理服务的云端主机，但后者没有可直接从公网访问的入站端口。两台机器加入同一个 Tailscale 网络后，可以通过 Tailscale 地址互相访问，不必先做端口转发。

这不是“自动解锁所有服务”的方案。目标网站仍可能根据账号、地区、IP 信誉、IPv4/IPv6、DNS、浏览器环境或服务政策做独立判断。原教程中关于 Gemini 和 Cloudflare 的结果属于作者个人实测，不能当作稳定保证。

🧰 准备工作与安全边界

开始前准备四样东西：

  1. 一台运行 Linux 和 3X-UI 的 VPS；
  2. 一台能够运行 SOCKS5 服务的云端主机；
  3. 一个 Tailscale 账号和对应的 tailnet；
  4. 保存配置、密钥和测试结果的本地目录。

建议第一次只做一个最小测试：单个域名、单个入站、IPv4 优先、短时间验证。不要一开始就把所有流量切到远端出口。

Auth Key 不要当普通密码用

Tailscale Auth Key 具备设备加入网络的权限。创建时尽量：

  • 设置较短的有效期；
  • 只在必要时启用可复用或临时设备选项；
  • 不把密钥写进公开脚本、截图或聊天记录；
  • 配置完成后，在 Tailscale 管理控制台撤销不再使用的密钥。

SOCKS5 也应启用用户名和密码，并限制为只监听 Tailscale 地址。不要把 SOCKS5 端口暴露到公网。

🔗 第一步：让两台机器加入同一个 Tailscale 网络

Tailscale 的作用是把分散在不同网络中的设备加入同一个加密的私有网络。设备上线后，会获得 Tailscale 地址，其他设备可以按权限互相访问。

Tailscale 虚拟组网示意图

在云端主机上配置

如果云端主机由可执行命令的 AI 助手管理，可以要求它完成以下任务：

在当前云端主机安装并配置 Tailscale。
创建一个仅监听 Tailscale 地址的 SOCKS5 服务，支持 TCP；
不要监听公网网卡，不要开放公网访问；
启用 SOCKS5 用户名和密码认证，并确保服务重启后能够恢复。
完成后只返回：Tailscale 地址、SOCKS5 端口、用户名、密码，以及服务状态。
不要输出 Auth Key。

这段提示词只是任务描述，不是某个云平台的官方 API。不同平台能否安装软件、是否保留服务状态，要以平台权限和实际执行结果为准。

Tailscale Auth Key 可在官方控制台的 Settings → Keys 页面创建：

https://console.tailscale.com/admin/settings/keys

在自己的 Linux VPS 上安装

官方安装入口：

https://tailscale.com/download

Linux 机器通常可以使用官方安装脚本：

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

执行 tailscale up 后，终端一般会给出认证链接。完成认证后，到 Tailscale 管理控制台的设备列表确认两台机器都在线。

通过检查点再继续

只有满足下面三项，才进入 3X-UI 配置：

  • 两台机器出现在同一个 tailnet；
  • 云端主机的 Tailscale 地址可以从本地 VPS 访问；
  • SOCKS5 只监听 Tailscale 网络，并且使用认证信息可以连接。

如果第二项失败，先检查 Tailscale ACL、设备状态和主机防火墙。不要直接在 3X-UI 里反复改路由。

⚙️ 第二步：在 3X-UI 添加 SOCKS5 出站

在 3X-UI 中打开“出站”，新建一个出站配置。核心字段可以按下表填写：

字段填写思路
协议socks
目标地址云端主机上 SOCKS5 服务的 Tailscale 地址
端口云端 SOCKS5 实际监听端口
用户名 / 密码SOCKS5 认证信息
网络协议初次测试可先选 IPv4
出站标签使用一个容易识别的名称，例如 cloud-socks

保存后先点 3X-UI 的测速或测试按钮。如果测试失败，按顺序检查：

  1. Tailscale 地址是否填错；
  2. SOCKS5 服务是否正在运行；
  3. 服务是否真的监听 Tailscale 地址；
  4. 端口和认证信息是否正确；
  5. 云端主机的本机防火墙是否允许来自 tailnet 的连接。

SOCKS5 出站与域名路由流程

测速通过后，再配置路由规则。不要跳过这一步，否则后面看到的失败可能来自出站连接，而不是域名规则。

🧭 第三步：添加路由规则，只转发需要的域名

打开“路由”，新建路由规则，将指定域名匹配到刚才创建的 cloud-socks 出站。

字段初次测试建议
网络Any，或按实际需求限定 TCP/UDP
域名只填写需要测试的域名
入站标签选择实际使用的入站
出站标签选择 cloud-socks

原教程以 domain:googleapis.com 作为 Gemini 相关请求的示例。这个域名规则只是示范，不代表完整服务依赖，也不保证覆盖登录、静态资源、区域接口或其他域名。若目标服务仍不可用，需要根据实际连接日志补充规则，而不是盲目把所有流量转发出去。

规则顺序很重要

多条路由同时存在时，先检查：

  • 更具体的域名规则是否排在通用规则之前；
  • 入站标签是否匹配实际流量入口；
  • 出站标签是否指向刚刚测试通过的 SOCKS5；
  • 是否存在强制直连、阻断或 IPv6 规则覆盖它。

保存后按 3X-UI 的提示重启相关服务或面板。重启前保留旧配置，避免一次改错导致所有节点失联。

🧪 第四步：验证出口，不要只看“配置成功”

验证分为三层，最好一层一层做。

1. 验证设备连接

确认 Tailscale 控制台显示两台设备在线，并且本地 VPS 可以访问云端主机的 Tailscale 地址。

2. 验证 SOCKS5 出站

在 3X-UI 中使用测速功能，或从 VPS 上用不会泄露敏感信息的测试请求验证代理连接。不要把用户名、密码、Auth Key 或完整配置粘到公共网站。

3. 验证最终公网 IP

可以使用 IP 检测网站，例如：

https://ping0.cc/

确认时要看实际请求是否经过指定入站和域名规则。直接在 VPS shell 中访问检测网站，只能证明 shell 的默认出口；它不能自动证明 3X-UI 节点流量已经命中规则。

网络出口配置检查清单

建议记录以下结果：

检查项结果
Tailscale 两端在线通过 / 失败
Tailscale 地址可达通过 / 失败
SOCKS5 认证通过 / 失败
3X-UI 出站测速通过 / 失败
路由规则命中通过 / 失败
目标域名看到的出口 IP记录实际结果

🛠️ 常见失败与回退方法

SOCKS5 连接不上

先回到 Tailscale 层检查地址和连通性，再检查 SOCKS5 监听地址、端口、防火墙和认证。不要先改目标域名。

测速通过，但目标服务仍不可用

这说明“能连上 SOCKS5”和“目标服务接受当前请求”是两件事。继续检查域名覆盖、DNS、IPv6、账号地区和目标平台政策。Gemini 或 Cloudflare 是否通过，不应由单个 IP 检测结果推断。

所有流量都被转发

通常是域名规则留空、规则顺序不当，或出站被配置成默认出口。先恢复直连规则，再只加入一个明确域名进行测试。

配置后节点失联

回退最近一次改动，检查入站标签和出站标签是否填反。每次只改一个主要变量，并保留可工作的旧配置。

云端主机重启后失效

检查 Tailscale 和 SOCKS5 是否设置为开机启动，确认云平台是否会回收临时环境，以及 Auth Key 是否过期。临时云电脑不一定提供稳定的服务生命周期。

⚠️ 使用边界

  • Tailscale 负责组网，不等于它会自动提供公网代理出口。
  • SOCKS5 账号密码、Tailscale Auth Key 和 3X-UI 面板凭据都属于敏感信息。
  • 不要把 SOCKS5 服务绑定到 0.0.0.0 后直接暴露公网。
  • 不要用这套配置绕过服务条款、地区限制、访问控制或安全验证。
  • “原生 IP”“没有 Cloudflare 验证”“成功解锁某服务”等说法需要以你的时间、账号、地区和目标服务实际结果为准。
  • 3X-UI 是第三方开源面板，安装前应查看项目文档、版本和安全公告；项目地址为 https://github.com/MHSanaei/3x-ui 。

❓ 常见问题

Q：没有公网 IP 的云端主机能做出口吗？
A：在两台设备都加入同一 tailnet、且云端主机上的 SOCKS5 只通过 Tailscale 地址可达时，可以作为这套组网方案的远端出口。能否长期运行取决于云平台和服务配置。

Q：为什么不直接把所有流量都走远端？
A：全量转发会增加延迟，也更难定位 DNS、IPv6 和规则问题。先按域名做小范围验证更容易回退。

Q：只改 googleapis.com 就一定能使用 Gemini 吗？
A：不一定。具体请求可能涉及多个域名和不同的网络条件，原教程中的规则是一个测试示例，不是完整清单。

Q：Tailscale 会自动改变 VPS 的公网 IP 吗？
A：不会。它只是建立设备之间的私有网络连接。只有应用流量明确经过远端 SOCKS5 出站时，目标网站才可能看到远端出口。

Q：如何判断到底是哪一层出错？
A：按“设备在线 → Tailscale 地址可达 → SOCKS5 认证 → 3X-UI 出站测速 → 路由规则命中 → 目标服务响应”的顺序排查，每次只改变一个变量。

本文根据公开教程和官方项目资料重新整理，保留可验证的配置思路，未把原作者的个人测试结果写成稳定承诺。内容仅供学习和自建网络实验使用，不构成对任何服务可用性的保证。