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