SSD Nodes Learn Hosting plans →
指南 Matt Connor作者: Matt Connor · 已更新 2026-09-25

俄羅斯儲存 VPS 放哪裡?延遲與 152-FZ

在俄羅斯部署儲存 VPS,吞吐量與封包遺失通常比 RTT 更關鍵;同時了解聯邦法律 152-FZ 如何區分自有封存資料與他人個人資料。

在俄羅斯時,儲存 VPS 應放在哪裡

從俄羅斯購買儲存 VPS 涉及兩項決策,其中只有一項是技術問題。技術問題是磁碟所在的位置;對大量儲存而言,關鍵在於吞吐量與封包遺失,而不是往返時間。法律問題則是要在其中儲存哪些內容,因為聯邦法律 No. 152-FZ 對待自有封存資料與他人的個人資料方式不同。

本指南不引用任何延遲數據。唯一重要的路徑,是您的連線與考慮中的伺服器之間的路徑,因此下方的每項測量都必須由您自行執行命令。

大量儲存作業中,往返時間為何幾乎不重要

往返時間(RTT)是單一封包抵達伺服器並返回所需的時間。這是最容易測量的數值,因此人們常用它選擇區域。若要傳送相片目錄或執行每晚備份,單靠 RTT 幾乎無法決定實際表現。

TCP(傳輸控制協定)不會傳送一個封包後等待。它會讓尚未收到確認的資料維持在傳輸途中,而 Linux 會自動將這個視窗擴大到數 MB。即使路徑的 RTT 為 50 ms,視窗展開後,單一資料流仍可傳輸數百 Mbps。RTT 會影響連線達到穩定速度所需的時間,但不會決定穩定後的傳輸速度。

RTT 只會在一種特定模式下造成明顯影響:每項操作都需要一次往返。將遠端磁碟掛載為檔案系統,然後複製 40,000 個小檔案時,每個檔案至少需要一次往返;開啟、寫入和關閉檔案時,通常還需要數次往返。無論購買多少頻寬,傳輸速度都會大致限制在每個 RTT 傳送一個檔案。因此,在相同連線上,會將資料封裝成大型物件並同時傳送多個物件的工具,例如 restic 或使用平行傳輸的 rclone,通常會大幅勝過掛載的遠端檔案系統。

封包遺失才是真正破壞長距離路徑的原因

距離會把少量的遺失率轉化為大幅的速度下降。這就是「ping 看起來正常,但傳輸速度很慢」的原因。Ubuntu 預設使用的壅塞控制機制是 CUBIC。它會將封包遺失視為壅塞,並縮小傳送視窗。重新建立這個視窗需要許多次往返。在長距離路徑上,每次往返都很慢。因此,在 50 ms 延遲下遺失 0.5 percent 的封包,對吞吐量造成的影響遠大於在 5 ms 延遲下遺失相同的 0.5 percent。

BBR 會根據測得的頻寬與延遲反應,而不是將每次封包遺失都視為壅塞。因此,對於偶爾遺失封包的長距離路徑,BBR 通常能維持較好的效能。在傳送端設定 BBR:在 VPS 上設定會影響下載,在自己的電腦上設定會影響上傳。

printf 'net.core.default_qdisc = fq\nnet.ipv4.tcp_congestion_control = bbr\n' | sudo tee /etc/sysctl.d/99-bbr.conf
sudo sysctl --system
sysctl net.ipv4.tcp_congestion_control

最後一個命令應輸出 net.ipv4.tcp_congestion_control = bbr。請使用 iperf3 比較設定前後的結果,不要直接假設設定已改善效能。在沒有封包遺失的乾淨路徑上,通常完全不會有任何變化。

實際上較接近的地區

Frankfurt、Amsterdam、Warsaw 和 Helsinki 是歐洲託管業者針對俄羅斯網路集中配置容量的地點,也是最常被建議的選擇。地圖上的距離無法可靠預測實際連線品質。俄羅斯 ISP 到 Helsinki 資料中心的流量,仍可能經過 Frankfurt 或 Stockholm;即使位於同一座城市,兩家業者使用的 transit 組合也可能大不相同。如果您位於烏拉山脈以東,西歐在各個層面都相距遙遠,而 Almaty 或 Yerevan 等地點有時反而能提供較佳的路由。

因此,不要只看地圖選擇。多數主機商會為每個地點提供測試 IP 位址和測試檔案。付款前先進行測試,並使用您實際要上傳資料的連線,不要使用位於不同網路上的手機。如果您也在比較費用與司法管轄權,EU 儲存型 VPS 的資料駐留與費用會更詳細說明歐洲方面的考量。

使用 mtr 測量自己的路徑

sudo apt update
sudo apt install -y mtr-tiny iperf3
sudo mtr -rwzbc 200 198.51.100.10

-r 會輸出報告並結束,-w 可避免主機名稱遭截斷,-z 會顯示每個躍點所屬的網路,-b 會同時顯示名稱與 IP 位址,-c 200 會執行 200 個週期,讓封包遺失百分比具有參考價值。

先查看最後一行。中間躍點出現封包遺失,但後續躍點未持續出現的情況,不代表你的路徑有封包遺失:路由器通常會降低產生 mtr 所需 ICMP 回應的優先順序,因此忙碌的核心路由器可能回報封包遺失,但仍能正常轉送你的網路流量。只有一路持續到最終躍點的封包遺失才是真正的問題。最終躍點的封包遺失率只要高於約 1 percent,就會嚴重影響大型上傳,而且更換傳輸工具也無法修正。

如果網路會過濾 ICMP,導致追蹤提早中止,請改用 TCP,並指定實際會使用的連接埠:

sudo mtr -rwc 100 -T -P 443 198.51.100.10

網路路由通常是不對稱的,因此也要從 VPS 朝自己的位址執行 mtr。如果家用連線位於 CGNAT(carrier grade network address translation)之後,外部無法連回你的位址,反向追蹤會在 ISP 內部中止。這是預期行為,不是故障。

使用 iperf3 測量吞吐量

在 VPS 上啟動伺服器,並只在測試期間開放連接埠:

sudo apt install -y iperf3
sudo ufw allow 5201/tcp
iperf3 -s -p 5201

接著,在存放要上傳資料的機器上執行:

iperf3 -c 198.51.100.10 -p 5201 -t 30 -P 1
iperf3 -c 198.51.100.10 -p 5201 -t 30 -P 4
iperf3 -c 198.51.100.10 -p 5201 -t 30 -P 4 -R

第一次執行會使用單一上傳串流,第二次會平行使用 4 個串流,而 -R 會反轉方向,讓 VPS 將資料傳送給你。請仔細比較前兩次結果。如果 4 個串流明顯快於 1 個串流,表示限制來自單一連線,也就是視窗大小或遺失復原機制;使用平行連線的傳輸工具即可達到完整速率。如果兩次執行顯示相同數值,表示你已找到實際上限。對大多數家用與小型辦公室網路而言,這個上限通常是你自己的上行頻寬,而不是伺服器所在位置造成的。

測試完成後,按下 Ctrl+C 停止伺服器,然後關閉連接埠。持續監聽的 iperf3 -s 會讓網際網路上的任何人消耗你的頻寬配額。

sudo ufw delete allow 5201/tcp

第 152-FZ 號法律如何規範俄羅斯境外的儲存 VPS

2006 年 7 月 27 日頒布的第 152-FZ 號聯邦法律《個人資料法》,就是人們所說的「資料在地化」依據。該法的 3 個條文會決定外國儲存 VPS 是否會對你造成問題。以下內容說明法律條文,不構成法律意見。

第 1 條第 2 款界定適用範圍。 個人為純粹的個人與家庭需求處理個人資料時,只要該處理未侵害資料所屬者的權利,本法不適用。你的家庭相片,以及你為自己執行的伺服器備份,都屬於這一範圍。

第 18 條第 5 款規定資料在地化要求。 該要求適用於 operator,也就是決定處理目的的人。自 2025 年 7 月 1 日起,條文內容已由指示改為禁止。根據 2025 年 2 月 28 日第 23-FZ 號聯邦法律所引入的文字,收集個人資料時,包括透過網際網路收集,不得使用位於俄羅斯聯邦境外的資料庫,記錄、系統化、累積、儲存、更新或擷取俄羅斯聯邦公民的個人資料;但第 6 條第 1 款第 2、3、4 及 8 項所列情況除外。同一要求的早期版本由 2014 年 7 月 21 日第 242-FZ 號聯邦法律引入,並於 2015 年 9 月 1 日生效。

第 12 條規範跨境傳輸。 根據自 2023 年 3 月 1 日起生效、由 2022 年 7 月 14 日第 266-FZ 號聯邦法律引入的版本,operator 在開始將個人資料傳輸至境外前,必須通知 Roskomnadzor,即聯邦通信、資訊科技及大眾媒體監督局。依第 22 條提交處理通知是另一項義務,與磁碟位於何處無關。

實務上的區分很明確。將自己的檔案存放在 Frankfurt 的儲存 VPS 上屬於個人使用,152-FZ 不適用。若你執行一項讓使用者註冊的服務,並只在同一個境外磁碟上保存其姓名、電話號碼及訂單歷史,你就是 operator;此時首先必須符合第 18 條第 5 款。

中間情況是備份,也是最容易出問題的情況。客戶資料庫 dump 仍包含其個人資料,因此不適用個人使用排除規定。主要資料庫位於俄羅斯境內時,將加密的次要副本存放在境外是否符合第 18 條第 5 款,必須由律師依現行條文判斷。不要根據網路上的文章,包括本文,逕自作出結論。以上法律編號可用於官方法律資訊入口網站的搜尋;該網站發布已套用所有修正內容的整合版法規文字。

上傳前先加密,讓主機始終只持有密文

用戶端加密表示資料會在你的電腦上加密,伺服器收到的是無法讀取的位元組。託管公司、主機所在的司法管轄區,以及任何能迫使託管公司提供資料的人,看到的內容都相同。剩下的問題是金鑰處理,而這會成為你全部的風險所在。

restic 預設會在你的電腦上加密每個區塊,儲存庫密碼也不會傳送到伺服器:

sudo apt install -y restic
restic init --repo sftp:backup@198.51.100.10:/srv/restic
restic --repo sftp:backup@198.51.100.10:/srv/restic backup ~/documents ~/photos

如果要建立可持續瀏覽的鏡像,rclone 提供一個 crypt remote,可包裝另一個 remote。執行 rclone config,先為 VPS 建立未加密的 remote,再建立第二個類型為 crypt 的 remote,將其 remote 設定指向第一個 remote 上的路徑,檔名加密選擇 standard,並設定密碼與 salt。

sudo apt install -y rclone
rclone config
rclone sync ~/photos secret:photos --transfers=8 --progress
rclone cryptcheck ~/photos secret:photos

在 crypt remote 上使用 rclone cryptcheck,不要使用純粹的 rclone check,因為 check 無法穿過加密層比對 checksum。將檔名加密設為 off 只會加入 .bin 副檔名,伺服器上仍可讀取所有名稱,因此除非有其他程式必須讀取這些名稱,否則請維持 standard。

如果只有單一封存檔,age 就已足夠。將下方的收件者替換為 age-keygen 為你顯示的公開金鑰:

sudo apt install -y age
age-keygen -o ~/.age-key.txt
grep -i 'public key' ~/.age-key.txt
age -r age1ql3z7hjy54pw3hyww5ayyfg7zqgvc7w3j2elw8zmrj2kg5sfn9aqmcac8p -o photos.tar.zst.age photos.tar.zst

加密不會隱藏所有資訊。伺服器仍可得知檔案大小、你保留多少物件、連線時間,以及每次傳輸的資料量。加密也不會改變法律分析,因為你持有金鑰的個人資料仍屬於個人資料:第 18 條第 5 款取決於資料庫所在位置,而不是主機是否能讀取資料。

必須坦白提醒一點。密碼就是資料本身。遺失密碼後,密文只是一串無法使用的內容,沒有復原途徑,也沒有任何支援工單能提供協助。請將密碼記錄在即使製作備份的電腦遺失後仍能取得的位置。在儲存 VPS 上加密資料會更深入說明金鑰處理。

從俄羅斯支付境外主機供應商

2022 年 3 月,Visa 和 Mastercard 暫停在俄羅斯的業務後,俄羅斯銀行核發的卡片便無法在俄羅斯境外使用;而國內的 Mir 系統也未獲多數主機商使用的付款處理商接受。許多主機商還會在註冊時進行制裁篩查,有些也會在每次續約時再次執行。截至 2026 年 9 月,多數歐洲和北美供應商仍維持這種狀況。

其後果比付款不便更重要。無法續約的儲存 VPS 就不再具備儲存功能。主機商通常會在短暫寬限期後暫停未付款的伺服器,並在更長的期限後刪除磁碟;這兩個期限都會載明於你結帳時接受的條款中。上傳 1 TB 資料前,請先閱讀這些條款,並將續約日期加入行事曆,設定在日期前很久觸發的提醒。

在決定儲存任何資料前,值得先確認兩件事:供應商針對你所在國家在結帳頁面實際提供哪些付款方式,以及價格是以歐元還是美元計價,因為以外幣計算的固定月費,換算成盧布後並不是固定的每月成本。本指南不提供規避供應商付款或制裁規則的方法。如果主機商不接受你的付款,請選擇接受付款的主機商。

Seeding 計算:第一次上傳需要多久

第一次上傳最耗時。之後只需傳送變更的內容,對相片和文件而言,通常只占很小的比例。計算方式只有一行:秒數等於位元組數乘以 8,再除以每秒位元數。若將 1 GB 計為 1,000,000,000 個位元組,500 GB 就是 4 trillion bits。

ChartTime to upload 500 GB at 80 percent of nominal uplink (computed, not measured)
The data behind this chart
[
  {
    "label": "10 Mbit/s uplink",
    "effective_mbit_s": 8,
    "hours_for_500_gb": 138.9
  },
  {
    "label": "40 Mbit/s uplink",
    "effective_mbit_s": 32,
    "hours_for_500_gb": 34.7
  },
  {
    "label": "100 Mbit/s uplink",
    "effective_mbit_s": 80,
    "hours_for_500_gb": 13.9
  },
  {
    "label": "500 Mbit/s uplink",
    "effective_mbit_s": 400,
    "hours_for_500_gb": 2.8
  },
  {
    "label": "1000 Mbit/s uplink",
    "effective_mbit_s": 800,
    "hours_for_500_gb": 1.4
  }
]

表格假設實際可用的上行頻寬為標稱值的 80%,這是為通訊協定額外負荷及家中其他使用者共用線路預留的合理比例。這些是計算結果,不是任何實際網路的測量值。將 iperf3 提供的速率代入相同計算,結果仍然適用。

在 10 Mbit/s 的上行連線上,500 GB 需要連續上傳 138.9 小時,接近 6 天。有效速率為 80 Mbit/s 時,需要 13.9 小時,也就是執行一整晚並延續到隔天早上。在 gigabit 線路上則需要 1.4 小時。這 5 列涵蓋大多數家庭與小型辦公室連線的範圍,趨勢很明顯:上傳時間取決於自己的上行頻寬,因此伺服器即使位於遠 2,000 公里的地方,在這裡幾乎不會增加成本。

有兩點實務注意事項。請在 tmux 中執行第一次上傳,或將其設定為 systemd 服務,避免關閉筆記型電腦時工作程序終止,因為 restic 和 rclone 都能從中斷處繼續。也請先閱讀 ISP 的合理使用政策,因為住宅方案可能會限制一週內上傳半 TB 這類流量。如果尚未決定容量,應先計算實際需要多少儲存空間,再由比較儲存 VPS 與 object storage 的每 TB 價格決定每個已上傳 TB 每月的成本。

在信任備份副本前先驗證還原

從未還原過的副本,只能算是推測。執行 3 個命令,就能確認副本是否可用。

restic --repo sftp:backup@198.51.100.10:/srv/restic snapshots
restic --repo sftp:backup@198.51.100.10:/srv/restic check --read-data-subset=5%
restic --repo sftp:backup@198.51.100.10:/srv/restic restore latest --target /tmp/restore-test --include /home/me/documents

單獨執行 check 會驗證儲存庫的結構與中繼資料,但不會下載任何檔案資料,因此無法發現遭截斷或損毀的 pack 檔案。--read-data-subset=5% 會下載並驗證 5 percent 的 pack 檔案,藉此找出這類損毀。所需頻寬會依指定比例增加,因此 500 GB 儲存庫的 5 percent 會下載 25 GB。相同旗標也接受 1/5 這類分數,以及 10G 這類大小值。

接著逐位元組比較實際檔案:

sha256sum ~/documents/report.pdf /tmp/restore-test/home/me/documents/report.pdf

兩個雜湊值完全相同,表示整個往返流程都成功,包含加密在內。

請使用你記下的密碼,在一台不是建立備份的機器上執行一次。這項測試能抓出真正的故障:儲存庫密碼只存在於那台已故障筆電的 shell 歷史記錄中。從未通過這項測試的遠端磁碟只能算是副本,不能算是備份。在依賴儲存 VPS 前,值得先閱讀儲存 VPS 是否本身就算備份。供應商端的 snapshot 也有相同限制,因為它們與要保護的伺服器位於相同基礎架構上,因此snapshot 與備份解決的是不同問題。

這套流程在一台伺服器上運作後,剩下的問題就是各台機器如何互相連線,而透過私有 tunnel 連接不同供應商的 2 台 VPS能讓這些流量不經過公開網際網路。如果你還在決定自己究竟需要哪一類伺服器,請先從儲存 VPS 與一般 VPS 有何不同開始。

FAQ

將自己的備份保存在俄羅斯境外的 storage VPS 合法嗎?

根據第 1 條第 2 款,聯邦法律 No. 152-FZ 不適用於自然人為純粹個人與家庭需求處理個人資料的情況,前提是該處理未侵害他人的權利。自己的照片,以及自己營運之伺服器的備份,屬於這種情況。當資料屬於他人時,情況便不同:此時您是資料處理者,第 18 條第 5 款的資料在地化要求即適用。該款內容由 2025 年 2 月 28 日的聯邦法律 No. 23-FZ 修訂,並自 2025 年 7 月 1 日起生效。以上說明的是法律條文內容,不構成法律意見;在依此建置服務前,請確認現行法規文字並諮詢專業意見。

用戶端加密是否符合 152-FZ 的在地化要求?

不符合。加密會改變 hosting provider 能讀取的內容。第 18 條第 5 款規範的是資料庫所在位置,而您持有解密金鑰的個人資料仍然是個人資料。仍應進行加密,因為這能在機密性方面將 hosting provider 及其司法管轄區排除在威脅模型之外;但在地化問題仍須分開判斷,並依其本身的法律要求處理。

為什麼連線到 VPS 的 ping 看起來正常,但傳輸速度很慢?

往返時間不等於吞吐量。最常見的兩個原因是封包遺失與每個檔案都需要額外的往返。封包遺失會使 CUBIC 擁塞控制縮小傳送視窗;在長距離路徑上,重建視窗需要多次緩慢的往返,因此即使只有不到 1% 的遺失,也可能消耗大量頻寬。透過掛載的遠端檔案系統複製許多小檔案時,每個檔案至少需要 1 次往返,無論連線本身能承載多少流量。先執行 iperf3 -c 198.51.100.10 -t 30 -P 1,再執行加入 -P 4 的相同命令:如果 4 個串流明顯快於 1 個串流,限制就在單一連線,而不是連線本身。

從俄羅斯選擇 Frankfurt、Amsterdam、Warsaw 或 Helsinki 時,應選哪個地區?

請測量,不要猜測。這 4 個地點都有能連往俄羅斯網路的 hosting provider,但您所使用的 ISP 採取的路由,比地圖上的距離更重要;即使位於同一城市,不同 provider 的結果也可能不同。請向每個 provider 索取測試 IP 位址,從實際上傳所用的連線,對每個候選地點執行 sudo mtr -rwzbc 200 <ip> 與 iperf3 測試,並選擇最終躍點封包遺失率最低的位置,而不是 ping 最低的位置。

第 1 次上傳 500 GB 需要多久?

將位元數除以有效上傳速率。500 GB 等於 4 兆個位元,因此在有效速率 80 Mbit/s 下,約需 13.9 小時;在有效速率 8 Mbit/s 下,約需 138.9 小時。這些是計算值,請代入 iperf3 在您自己的線路上測得的速率。請在 tmux 中執行上傳,或將其設為 systemd 服務,避免連線中斷後必須從頭開始;開始前也請確認 ISP 的合理使用政策。