Shadowsocks 服务端部署：匹配密钥、验证流量与备份恢复

Shadowsocks 服务端部署：匹配密钥、验证流量与备份恢复

Ryan Foster
2026年10月11日· 8 分钟阅读

Shadowsocks 服务端部署应从具体实现和匹配的客户端密钥开始，不能把其他项目的配置当成通用模板。本教程固定 shadowsocks-rust，采用一种官方记录的 2022 密码方案，并区分本地应用代理与整台设备的流量覆盖。

关键要点

  • 实现、密码方案、密钥、端点和传输模式必须一致。
  • 2022 密钥不是随意设置的易记密码。
  • 应用 TCP、UDP 和错误密钥拒绝要分别验证。
  • 本例共享密钥轮换会撤销全部使用旧值的客户端。

此 Shadowsocks 服务端部署覆盖哪些流量？

先用自建节点责任指南规划独立管理与恢复。选择覆盖范围前，比较全隧道与应用代理。本例只影响显式配置的测试应用及受控 UDP 转发监听，不安装 TUN、不改全局路由，也不提供断网保护。

Shadowsocks 概述解释协议边界。若维护主机不是目的，应比较VPS 自维护与托管出口。配对的Hysteria2 部署使用不同 UDP 传输及证书要求，不能把它的字段混进本流程。

**适用范围与证据：**专用 Ubuntu 24.04 LTS x86-64 服务器、独立且获授权 Linux 客户端、公网 IPv4，两端均为 shadowsocks-rust v1.25.0。本文限定 Rust 实现，不是 Python、libev、面板或未说明的客户端应用。未报告作者端到端实测，预期结果是按官方资料制定的读者验收条件。其他架构须使用对应官方发行文件。［1］［2］［3］

步骤 1：保留管理入口并获取 Shadowsocks Rust 服务端

确认新的 SSH 连接及云平台控制台独立于代理。私下记录原有监听、路由、DNS、防火墙归属、服务和费用。预留服务器 TCP/UDP 8388，以及客户端 TCP 1080、UDP 19001。若冲突，或已有 shadowsocks-ops 路径、服务单元、用户就停止，不接管他人服务。

从 Ubuntu 可信软件包安装缺少的 curl、ca-certificates、xz-utils 和 Python 3。在新建私有工作目录下载指定官方归档及对应校验文件。逐条执行，任何一步失败就停止；校验成功前不能解包或执行。

umask 077
mkdir shadowsocks-1.25.0-reader
cd shadowsocks-1.25.0-reader
curl --fail --show-error --location \
  https://github.com/shadowsocks/shadowsocks-rust/releases/download/v1.25.0/shadowsocks-v1.25.0.x86_64-unknown-linux-gnu.tar.xz \
  -o shadowsocks-v1.25.0.x86_64-unknown-linux-gnu.tar.xz
curl --fail --show-error --location \
  https://github.com/shadowsocks/shadowsocks-rust/releases/download/v1.25.0/shadowsocks-v1.25.0.x86_64-unknown-linux-gnu.tar.xz.sha256 \
  -o shadowsocks-v1.25.0.x86_64-unknown-linux-gnu.tar.xz.sha256
sha256sum --check shadowsocks-v1.25.0.x86_64-unknown-linux-gnu.tar.xz.sha256

校验和确认文件与官方发行文件一致，不是独立发布者签名。还应核对项目归属与可取得的发行来源依据。先检查归档列表有无异常路径，再以非特权用户解包。预期二进制位于解包根目录；布局不同应停止调查，不能猜测带特权的复制命令。［1］［2］

tar -tf shadowsocks-v1.25.0.x86_64-unknown-linux-gnu.tar.xz
tar -xf shadowsocks-v1.25.0.x86_64-unknown-linux-gnu.tar.xz
./ssserver --version
./sslocal --version
./ssservice genkey -m "2022-blake3-aes-128-gcm"
sudo install -m 755 ssserver /usr/local/bin/ssserver-ops
sudo useradd --system --home /nonexistent --shell /usr/sbin/nologin shadowsocks-ops
sudo install -d -o root -g shadowsocks-ops -m 750 /etc/shadowsocks-ops

两个版本命令都应对应 1.25.0。保护归档及验证依据副本。生成器输出的是秘密，终端保持私密，直接存入密码管理器，不贴公开讨论或放入命令参数。

步骤 2：为 Shadowsocks 2022 部署匹配方案与密钥

固定使用 2022-blake3-aes-128-gcm。password 字段须是此方案生成的 16 字节密钥的 Base64 表示。普通 AEAD 密码派生与 2022 密钥是不同契约，不要换成人类易记密码、256 位方案的密钥、冒号分隔的多用户形式或其他项目默认值。［2］［4］

用 root 编辑器建立 /etc/shadowsocks-ops/server.json，将占位符换成生成密钥。占位符刻意不能直接使用。保持 JSON 语法正确，此严格 JSON 示例不能插入注释。

{
  "server": "0.0.0.0",
  "server_port": 8388,
  "method": "2022-blake3-aes-128-gcm",
  "password": "REPLACE_WITH_GENERATED_2022_KEY",
  "mode": "tcp_and_udp"
}

0.0.0.0 是服务端监听地址，绝不是客户端目标。本原生示例不使用 TLS 证书或插件；共享密钥是必要认证材料，不是证书私钥。不能为连通错误客户端而改用 none、plain 或弃用的流密码。

AEAD-2022 将时间戳检查用于重放保护，应通过可信时间服务确认两端时钟正常。时钟故障要排查，不应关闭协议保护。［4］

步骤 3：启动受限服务并仅开放所需端口

将以下专用服务单元存为 /etc/systemd/system/shadowsocks-ops.service。高端口 8388 允许非特权服务用户运行，不需要 root 网络能力或特权容器。

[Unit]
Description=Dedicated Shadowsocks Rust reader deployment
After=network-online.target
Wants=network-online.target

[Service]
User=shadowsocks-ops
Group=shadowsocks-ops
ExecStart=/usr/local/bin/ssserver-ops -c /etc/shadowsocks-ops/server.json
Restart=no
NoNewPrivileges=true
PrivateTmp=true
ProtectHome=true
ProtectSystem=strict

[Install]
WantedBy=multi-user.target

保留 SSH 和无关防火墙规则。通过实际云端及主机防火墙管理方，初期只允许测试客户端来源访问 TCP 与 UDP 8388。若批准策略只允许 TCP，就记录 UDP 不可用，不能算验证成功。不要清空规则，也不要开放本地 SOCKS 来解决远端连通。

sudo chown root:shadowsocks-ops /etc/shadowsocks-ops/server.json
sudo chmod 640 /etc/shadowsocks-ops/server.json
sudo systemctl daemon-reload
sudo systemctl start shadowsocks-ops
sudo systemctl status shadowsocks-ops --no-pager
sudo ss -lntup

预期所选服务持续运行，IPv4 8388 有两种传输监听。启动失败时保持入口关闭，根据私有日志分开排查 JSON、方案或密钥格式不支持、文件权限、架构、时钟与端口冲突。绑定成功不能证明密钥一致或应用转发正常。

步骤 4：配置客户端并验证 TCP 与拒绝行为

在独立 Linux 客户端按前述流程取得并验证同版本对应发行文件，保留 sslocal 和 ssservice。将 ss.example.com 换成服务器真实可达 IPv4 或域名，任何已发布 AAAA 都应符合另行设计的 IPv6 路径。两端必须使用相同方案与密钥。

UDP 练习还需要你控制且获授权的回显响应端，替换 udp-check.example.net:9001，并能从服务器访问。此名称不是公共测试服务。没有响应端就保留 UDP 为未验证。确认选定构建支持官方记录的 local-tunnel 功能，不支持协议时停止，不能私下更换实现。［2］

{
  "server": "ss.example.com",
  "server_port": 8388,
  "method": "2022-blake3-aes-128-gcm",
  "password": "REPLACE_WITH_GENERATED_2022_KEY",
  "locals": [
    {
      "protocol": "socks",
      "local_address": "127.0.0.1",
      "local_port": 1080,
      "mode": "tcp_only"
    },
    {
      "protocol": "tunnel",
      "local_address": "127.0.0.1",
      "local_port": 19001,
      "forward_address": "udp-check.example.net",
      "forward_port": 9001,
      "mode": "udp_only"
    }
  ]
}

SOCKS 监听刻意只处理 TCP；独立 tunnel 项是应用 UDP 测试路径，两者都只绑定回环。在私有目录启动客户端，并检查没有意外局域网监听。

chmod 600 client.json
./sslocal -c client.json

测试浏览器显式选 SOCKS5 127.0.0.1:1080，支持时让代理端解析域名。发起新的 HTTPS 请求，检查可见出口 IP，与服务器已知出口比对。只有监听或“已连接”标识不够。

反向检查时停止客户端并私下复制配置。用同一生成器、同一方案生成另一把格式正确的密钥，只替换副本的 password，保留地址与方案。启动该配置并发起新代理请求，应无法承载流量。访问服务器前就发生的 Base64 错误不能证明服务器拒绝。若流量通过，关闭入口，排查直连回退、另一运行配置及服务器实际密钥。

步骤 5：验证 UDP 并记录流量边界

切回有效配置，经 127.0.0.1:19001 转发发送一次受控 UDP 回显。下列读者命令预期收到获授权响应端返回的相同内容；本文没有声称已观察到输出。

python3 - <<'CHECK'
import socket
with socket.socket(socket.AF_INET, socket.SOCK_DGRAM) as sock:
    sock.settimeout(3)
    sock.sendto(b"reader-check", ("127.0.0.1", 19001))
    data, _ = sock.recvfrom(1024)
    assert data == b"reader-check", "Unexpected UDP reply"
CHECK
检查读者应取得的证据失败处理
应用 TCP新代理 HTTPS 请求与预期出口分开查浏览器、密钥、服务器出口及目标
应用 UDP回显与发送内容相同查客户端转发、两端 UDP 规则、服务端模式及回程
DNS应用解析遵循所选策略独立检查本地与代理解析，不凭出口 IP 推断
IPv6适用应用路径明确纳入或排除IPv4 验收不等于整机保护
断连测试应用按设置报错或回退预期失败策略未确认前停止敏感活动
开放代理未授权及错误密钥不能中继，SOCKS 保持回环立即关入口，修正绑定或认证

再用错误密钥配置发送同一受控 UDP 请求，不能收到认证中继回包。超时本身原因很多，须在反向检查前后保留有效密钥的成功对照。来源限制是认证的补充；若全部请求被防火墙挡下，就不能独立证明密钥拒绝。

步骤 6：轮换、恢复、重启与退役

在授权维护窗口重启服务器，重复正确与错误密钥的 TCP/UDP 检查。验收并确认重启后保护配置仍可读，才启用自动启动。

撤销时先关闭本次部署入口，生成同方案新密钥，替换服务端值，再重启终止现有会话。只更新保留客户端。单密钥基线撤销所有使用旧值的客户端，不按设备标签隔离。将轮换记录另存于备份外，随后再次重启，确认旧密钥拒绝、保留客户端正常。

一致性备份只停止此服务单元。以下目标目录不得存在，已存在就停止。每条命令都以前条成功为条件；复制失败时保留源文件，主动恢复已知正常状态，不能删除源配置。

sudo systemctl stop shadowsocks-ops
sudo install -d -m 700 /root/shadowsocks-backup-20261011
sudo cp -a /etc/shadowsocks-ops /root/shadowsocks-backup-20261011/
sudo cp -a /usr/local/bin/ssserver-ops /root/shadowsocks-backup-20261011/
sudo cp -a /etc/systemd/system/shadowsocks-ops.service /root/shadowsocks-backup-20261011/
sudo chmod -R go-rwx /root/shadowsocks-backup-20261011
sudo systemctl start shadowsocks-ops

恢复计划中另存防火墙记录、客户端构建、文件属主及权限、外部轮换清单。归档包含认证密钥，应先加密再放到受限异机存储，不公开或留下所有人可读的副本。

在同版本隔离替代机、入口关闭时恢复：将二进制与服务单元放回指定路径，重建服务用户，把配置目录复制到 /etc/shadowsocks-ops。启动前重新设置目录 root:shadowsocks-ops、权限 750，配置属主 root:shadowsocks-ops、权限 640，二进制 755、服务单元 644。先从独立清单应用当前密钥，再重新加载 systemd 并启动。开放前重复正向、反向、UDP 及重启检查，不能让旧归档复活已撤销密钥。

退役时只关闭此服务 TCP/UDP 规则，停止并禁用 shadowsocks-ops，停止客户端，恢复测试应用原代理设置，确认本地 1080/19001 监听消失。决定保留期限后，只删创建的服务单元、二进制、文件和用户，重载 systemd，另查 DNS 及云资源。独立确认新 SSH 登录和原有服务。移除软件不取消计费；恢复不确定就停止后续变更。

总结

  • 两端固定 Rust 版本、确切密码方案及生成密钥。
  • TCP、UDP、DNS、IPv6 和失败行为分别决定覆盖范围。
  • 重启和恢复后拒绝旧密钥，只清理本次创建资源。

常见问题

2022 方案可以用熟悉的密码吗？

不能。此方案要求特定长度密钥的 Base64 表示。应使用该实现指定方案的生成器，并将生成值作为秘密保护。

可以原样使用 libev 或 Python 配置吗？

不同实现的功能和字段契约不同。本文两端固定 Rust v1.25.0，其他实现须独立验证，不能直接混合示例假定兼容。

浏览器 TCP 成功能证明 UDP 可用吗？

不能。UDP 需要独立客户端模式、服务端设置、防火墙路径和受控响应端，应与浏览器请求分别验收记录。

这会保护设备上的每个应用吗？

只覆盖显式设置的应用流量及示例转发监听。整机路由和断网保护需要另外设计、独立验证，不能据此推断。

单密钥服务器能独立撤销一台设备吗？

本基线全部客户端共享服务器密钥，轮换会影响所有使用者。独立身份需要其他受支持配置及相应验收计划。

TCP 端口开放就代表出现开放代理吗？

加密监听可达不能证明未授权中继。要检查错误密钥拒绝和本地 SOCKS 绑定，并保留有效密钥对照以区分认证与网络失败。

作者执行过部署及恢复吗？

本文不声称端到端实测。命令定义读者检查；验收前要记录实际版本、授权资源、网络、结果与恢复证据。

来源:

  1. shadowsocks-rust v1.25.0 — https://github.com/shadowsocks/shadowsocks-rust/releases/tag/v1.25.0
  2. shadowsocks-rust v1.25.0 — README — https://github.com/shadowsocks/shadowsocks-rust/blob/v1.25.0/README.md
  3. Shadowsocks — Deploying — https://shadowsocks.org/doc/deploying.html
  4. Shadowsocks 2022 — Specification — https://shadowsocks.org/doc/sip022.html

Sources checked 2026 年 10 月 11 日。

延伸阅读:

开启 3 天免费试用

注册即可免费体验全部高级功能。

*仅限新用户；每位用户只能获得一次试用。

免费试用

相关文章

Shadowsocks 服务端部署：匹配密钥、验证流量与备份恢复 | AethoVPN