SSD Nodes Learn 8GB 記憶體 — 每年 $66
指南 Matt Connor作者： Matt Connor · 已更新 2026-08-01

交易機器人 VPS 怎麼選？真正重要的 4 件事

交易機器人選 VPS 不只看速度：了解 systemd 自動重啟、UTC 時鐘、API 金鑰防護、heartbeat，以及零售交易可達到的真實延遲限制。

交易機器人需要 VPS 提供什麼

評估用於交易機器人的 VPS 時，主要看四件事：程序終止後是否會自動恢復、系統時鐘是否正確、API（應用程式介面）金鑰是否難以遭竊，以及程序停止時能否及時得知。對零售交易機器人而言，純粹的速度遠不如上述因素重要，因為訂單路徑中最慢的部分是您的經紀商與您和經紀商之間的距離，而不是執行 Python 的主機。

本指南說明工程實務。不包含任何財務建議，也不討論任何策略。

正常運作時間取決於重新啟動管理，而不是銷售頁面上的數字

全球每台主機都宣稱 99.9% 的正常運作時間。這個數字描述的是 hypervisor，不是你的 bot。bot 可能因未處理的例外、永不重新連線的 websocket，或 OOM (out of memory) killer 而停止，但伺服器始終保持運作。因此，有用的問題是：你的程序結束後的 10 秒內會發生什麼事。

將 bot 執行為 systemd 服務，並讓 init system 負責重新啟動。unit file 只需 6 行即可完成這項設定。

[Unit]
Description=Trading bot
After=network-online.target
Wants=network-online.target
StartLimitIntervalSec=0

[Service]
Type=simple
User=bot
WorkingDirectory=/opt/tradingbot
EnvironmentFile=/etc/tradingbot/api.env
ExecStart=/opt/tradingbot/venv/bin/python -m tradingbot
Restart=always
RestartSec=10
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
ReadWritePaths=/var/lib/tradingbot

[Install]
WantedBy=multi-user.target

StartLimitIntervalSec=0 是人們容易遺漏的設定。依預設，systemd 在 10 秒內重新啟動 5 次後就會放棄，並讓 unit 永遠處於 failed 狀態。這正是你不希望在 03:00 發生的行為。將其設為 0 可停用速率限制，因此持續 crash-loop 的 bot 會繼續嘗試，而不是停止運作。RestartSec=10 可避免這個迴圈透過反覆重新連線持續對交易所造成負載。

先檢查檔案，確認無誤後再啟動：

sudo systemd-analyze verify /etc/systemd/system/tradingbot.service
sudo systemctl daemon-reload
sudo systemctl enable --now tradingbot
systemctl status tradingbot

enable 是能在重新啟動後持續運作的部分，而 kernel 更新代表需要重新啟動。若要確認 bot 是否一直在背景中停止，請要求 systemd 顯示重新啟動計數器：

systemctl show tradingbot -p NRestarts
journalctl -u tradingbot --since "24 hours ago" | tail -50

一週後顯示 NRestarts=0 代表 bot 運作正常。NRestarts=812 表示你一直在使用整晚反覆重新連線的程序進行交易。完整的 unit file 結構，包括每日報告等排程工作的 timer，請參閱將程式執行為 systemd 服務。

將時鐘設為 UTC，並確認已同步

交易所 API 會使用時間戳記簽署要求，並拒絕超出時間窗口的要求，通常限制為 5 秒或更短。時鐘偏移會產生看似驗證失敗的錯誤，因此使用者可能花數小時輪換金鑰，卻未先檢查時間。在 Binance-style API 上，訊息內容很明確：Timestamp for this request was 1000ms ahead of the server's time。

將伺服器設為 UTC。當地時區會引入日光節約時間跳變，可能在交易時段中途發生。

sudo timedatectl set-timezone UTC
timedatectl

Ubuntu 隨附 systemd-timesyncd，這是一個 SNTP（簡易網路時間協定）用戶端。它適合記錄日誌，但不適合需要維持在幾毫秒內的用途，因為它只輪詢一台伺服器，且不會持續校準時鐘。改用 chrony：

sudo apt update && sudo apt install -y chrony
sudo systemctl enable --now chrony
chronyc tracking
chronyc sources -v

從 chronyc tracking 讀取的行是 System time，例如 System time : 0.000031415 seconds fast of NTP time。低於幾毫秒表示狀態正常。如果讀到 Leap status : Not synchronised，表示 chrony 尚未連線到伺服器，通常是因為對外 UDP 123 被封鎖。等待 1 分鐘後再檢查一次，再處理防火牆規則。

將 API 金鑰排除在會複製的目錄之外

洩漏的交易所金鑰比洩漏的 SSH 金鑰更嚴重，因為提款權限會立即轉化為金錢。兩個習慣即可涵蓋大部分風險。

首先，絕對不要將提款權限授予機器人金鑰。如果交易所支援，請將金鑰綁定至伺服器的 IP 位址。這是唯一能讓遭竊金鑰幾乎失去用途的控制措施。

其次，請將密鑰排除在程式碼目錄之外。/opt/tradingbot 中的任何內容，遲早都會進入 git repository 或備份封存檔。請將密鑰放在由 root 擁有、且僅由 systemd 讀取的檔案中：

sudo install -d -m 750 -o root -g bot /etc/tradingbot
sudo install -m 640 -o root -g bot /dev/null /etc/tradingbot/api.env
sudo nano /etc/tradingbot/api.env

檔案包含不加引號且不含 export 的純 KEY=value 行。權限模式 640 並使用群組 bot，表示服務使用者可以讀取，其他人則無法讀取。使用 sudo -u bot cat /etc/tradingbot/api.env 驗證，接著使用其他使用者驗證；後者必須因 Permission denied 而失敗。

機器人本身不應以 root 或您的登入使用者身分執行。請建立沒有 shell 且沒有可供登入的 home directory 的系統帳戶：

sudo useradd --system --shell /usr/sbin/nologin --home-dir /var/lib/tradingbot --create-home bot

以未具特殊權限的使用者身分執行服務 中說明了各個旗標的用途，以及 ProtectSystem=strict 實際能達到的效果。伺服器的其餘基準設定，包括 SSH 金鑰和防火牆，應放在新 VPS 上線後的前 10 分鐘中。

在經紀商發現前確認服務已停止

systemctl status 表示程序正在執行，但不表示交易機器人正在執行工作。針對已失效 websocket 持續重試的程序，仍可能通過 systemd 能執行的所有檢查。

改用 heartbeat。Uptime Kuma 支援 push monitors：它會預期交易機器人按排程呼叫 URL，並在停止收到呼叫時發出警示。將呼叫放在主迴圈的末端，並置於能證明交易機器人仍正常運作的部分之後，例如成功讀取市場資料。

curl -fsS "http://monitor.example.com:3001/api/push/YOUR_TOKEN?status=up&msg=loop_ok"

將 monitor 間隔設為迴圈執行時間的大約 2 倍，避免正常的延遲抖動觸發通知。請在不同於交易機器人的伺服器上執行 monitor，因為若 monitor 與其監控的對象一同停止，就不會回報任何資訊。設定方式請參閱 使用 Uptime Kuma 進行自行託管的狀態監控。

另外加入磁碟警示。持續寫入詳細記錄的交易機器人會在數週內填滿 root 檔案系統，而磁碟填滿會停止資料庫寫入，不會停止網路呼叫，因此症狀會很奇怪。journalctl --vacuum-time=14d 和 /etc/systemd/journald.conf 中的 SystemMaxUse= 行可限制 journal 的大小。

誠實面：延遲大多不是由主機造成

這是交易 VPS 產品市場不再著重技術的地方。行銷頁面會列出低於 1 毫秒的數據，並暗示主機是你與成交之間的關鍵。但對幾乎所有零售交易機器人而言，事實並非如此。

你的訂單會經由公用網際網路，從機器人傳送至交易所或經紀商端點。這條路徑主要受實體距離，以及你的服務供應商與對方供應商之間的對等連線影響。位於 Frankfurt 的伺服器與 Tokyo 的端點通訊時，無論 CPU 多快，往返時間大約都要 250 毫秒。接著，經紀商自身的系統還會加入佇列、風險檢查和速率限制；對零售帳戶而言，這些延遲通常以數十或數百毫秒計算。

請實際測量，不要猜測。curl 會回報實際端點的連線時間和第一個位元組的回應時間：

curl -s -o /dev/null -w 'dns=%{time_namelookup}s connect=%{time_connect}s ttfb=%{time_starttransfer}s\n' \
  https://api.kraken.com/0/public/Time
mtr -rwzc 100 api.kraken.com

在決定使用候選伺服器之前，先從該伺服器執行這項測試。如果 connect 是 0.180 秒，表示伺服器位於錯誤的大陸，這值得修正。如果 connect 是 0.004 秒，而 ttfb 是 0.140 秒，剩餘延遲就是經紀商的處理時間，變更主機無法改善這一點。

那麼，主機何時才重要？當你與交易場所共置或透過交叉連線接入，並且需要競爭佇列位置時。這是不同的業務，預算也不同。此外，如果瓶頸在你的程式碼中，主機也會變得重要：每個 tick 都針對完整歷史資料重新計算指標的機器人，每次迴圈可能耗用 200 毫秒的 CPU 時間。這是真正可由你控制、且不需額外費用的延遲。先分析迴圈的效能，再考慮購買更快的伺服器。

選擇主機時真正重要的是地理位置、穩定的網路連線，以及足夠的記憶體，確保 OOM killer 永遠不會介入。截至 July 2026，使用 Python、在記憶體中保存數百個交易標的的單一策略機器人，使用 2 GB RAM 和 2 vCPU 即可順暢運作。如果你要在本機資料庫中保存 tick 歷史資料，請增加記憶體。

上線前簡短檢查清單

  1. systemctl is-enabled tradingbot 會輸出 enabled，且服務在執行 sudo reboot 後仍能正常運作。
  2. chronyc tracking 回報的系統時間偏移低於數毫秒。
  3. API 金鑰具備交易權限，但不具備提款權限；如果交易所提供 IP allowlist，也應設定該清單。
  4. 使用 sudo systemctl kill -s SIGKILL tradingbot 終止程序後，程序會在 RestartSec 內重新啟動。
  5. 當您刻意停止交易機器人時，heartbeat monitor 會在一個監控間隔內傳送 page 通知給您。
  6. 日誌大小受到限制，且 root 檔案系統在 df -h 中仍有足夠可用空間。

在使用真實資金前，請先在交易所的 sandbox 或 paper mode 中完整執行一週。上述每個項目在這一週內至少會失敗一次，這正是進行一週測試的目的。

FAQ

交易機器人需要低延遲或裸機伺服器嗎？

只有在相同交易場所中，您需要與其他自動化參與者競爭執行速度時才需要。這通常表示使用共置服務，而不是一般用途的 VPS。對零售交易機器人而言，往返延遲主要取決於地理位置和經紀商自身的處理時間。因此，請選擇靠近 API endpoint 的伺服器，並先使用 curl 和 mtr 測量，再決定是否支付更高的速度費用。

交易機器人需要多少 RAM 和 CPU？

大多數單一策略的機器人受網路限制，事件之間通常處於閒置狀態。截至 2026 年 7 月，2 vCPU 和 2 GB RAM 足以執行追蹤數百個商品的 Python 機器人。當您將 tick 歷史資料保留在程序中，或執行本機資料庫時，記憶體可能成為限制。因此，請監控 free -h 並檢查 journal 中的 OOM kill 訊息，不要自行猜測。

為什麼我的交易所 API 會因時間戳記錯誤而拒絕請求？

伺服器時鐘已漂移到交易所簽章允許的時間範圍之外，通常只差幾秒。請安裝 chrony，確認 chronyc tracking 顯示小幅的 System time 偏移，且 leap 狀態已同步。並將機器設定為 UTC，避免日光節約時間變更導致時間偏移。輪替 API key 無法修復時鐘問題。

如何避免機器人在夜間停止，而我完全不知道？

請使用 systemd 搭配 Restart=always 和 StartLimitIntervalSec=0 執行機器人。如此一來，發生崩潰迴圈時會持續重試，而不會永久停止。接著加入 heartbeat，讓機器人在每次成功迴圈結束時傳送訊號。重新啟動機制負責處理程序。heartbeat 則可發現程序仍在執行但已卡住的情況。

我可以在同一個 VPS 上執行機器人和監控服務嗎？

可以，但在真正發生問題的那天，監控服務會提供錯誤資訊。因為導致機器人停止的中斷也會同時使監控服務停止。請將警示服務放在不同的機器上，最好使用不同的供應商或區域。機器人的伺服器僅用於執行機器人及儲存其日誌。

#trading#bots#vps#uptime#systemd#monitoring