SSD Nodes Learn Hosting plans →
指南 Matt Connor作者： Matt Connor · 已更新 2026-08-07

交易 bot VPS 怎麼選？真正重要的 5 個條件

了解交易 bot 選 VPS 真正需要的條件：systemd 自動重啟、UTC 時鐘、API key 防護、heartbeat，以及誠實看待延遲限制。

VPS 對交易 bot 的需求

交易 bot 使用的 VPS 主要取決於 4 件事：程序停止後是否會自動恢復、系統時間是否正確、API (application programming interface) key 是否難以遭竊，以及停止運作時是否能及時得知。對零售交易 bot 而言，原始速度的重要性遠低於這些條件，因為訂單路徑中較慢的部分是 broker 及其與你的距離，而不是執行 Python 的主機。

這是一份工程實作指南。本文不提供任何金融建議，也不討論任何策略。

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

全球每台主機都宣稱具備 99.9 percent 的正常運作時間。這個數字描述的是 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 結構，包括每日報告等排程工作所需的 timers，請參閱 將程式作為 systemd 服務執行。

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

交易所 API 會使用時間戳記簽署請求，並拒絕超出允許時間範圍的請求，通常是 5 秒或更短。時鐘漂移會產生看似驗證失敗的錯誤，因此有些人會花數小時輪替金鑰，卻沒有先檢查時間。在 Binance 類型的 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 被封鎖。等待一分鐘後再檢查，確認結果前不要修改防火牆規則。

讓 API keys 遠離你會複製的地方

交換平台的 key 外洩，比 SSH key 外洩更嚴重，因為提款權限會讓它立即變成資金。以下兩個習慣可以涵蓋大部分風險。

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

其次，將 secret 移出程式碼目錄。/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 而失敗。

Bot 本身不應以 root 或你的登入使用者身分執行。請建立一個沒有 shell 且沒有可供登入之 home directory 的 system account：

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

以非特權使用者執行服務說明上述各個 flag 的用途，以及 ProtectSystem=strict 實際能達到的限制。伺服器的其餘基準設定，包括 SSH keys 與 firewall，請參閱新 VPS 上線後的前 10 分鐘。

在券商發現服務中斷前先得知狀況

systemctl status 表示程序正在執行，但不表示 bot 正在處理任何工作。針對失效 websocket 持續重試的程序，仍可能通過 systemd 能執行的所有檢查。

改用 heartbeat。Uptime Kuma 提供 push monitor：它會預期 bot 依排程呼叫 URL，並在停止收到呼叫時發出警示。將呼叫放在主迴圈末端，且必須位於能證明 bot 正常運作的步驟之後，例如成功讀取市場資料。

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

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

另外加入磁碟警示。持續寫入詳細日誌的 bot 可能在數週內填滿 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、記憶體中載入數百個 symbols 的單一策略機器人，使用 2 GB RAM 與 2 vCPU 即可穩定運作。如果要在本機資料庫保存 tick 歷史資料，請增加記憶體。

上線前簡要檢查清單

  1. systemctl is-enabled tradingbot 輸出 enabled，且服務在 sudo reboot 後仍能正常運作。
  2. chronyc tracking 顯示系統時間偏移量低於幾毫秒。
  3. API key 具備交易權限，但沒有提款權限；如果交易所提供 IP allowlist，也應加以設定。
  4. 使用 sudo systemctl kill -s SIGKILL tradingbot 終止程序後，程序會在 RestartSec 內重新啟動。
  5. 刻意停止 bot 時，heartbeat monitor 會在一個檢查週期內向你發出告警。
  6. 日誌大小受到限制，且 root 檔案系統在 df -h 中仍有足夠可用空間。

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

FAQ

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

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

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

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

為什麼交易所 API 會因 timestamp 錯誤拒絕我的請求？

伺服器時鐘已漂移到交易所簽章允許的時間範圍之外，通常只有數秒。請安裝 chrony，確認 chronyc tracking 顯示的 System time 偏移量很小，且 leap status 已同步；同時將機器設為 UTC，避免日光節約時間變更造成時間偏移。輪替 API key 無法修正時鐘問題。

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

請使用 Restart=always 和 StartLimitIntervalSec=0，讓交易機器人在 systemd 下執行。如此一來，發生當機時會持續重試，而不會永久停止。接著加入 heartbeat，讓機器人在每次成功完成迴圈後傳送。restart 機制負責處理程序。heartbeat 則能發現程序仍在執行但已卡住的情況。

可以在同一台 VPS 上執行交易機器人和監控服務嗎？

可以，但到了真正需要監控的那天，監控服務會提供錯誤資訊，因為導致交易機器人停止的中斷也會同時讓監控服務停止。請將告警服務放在另一台機器上，最好使用不同的 provider 或 region；交易機器人的伺服器只用於執行機器人及保存其 log。

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