交易机器人 VPS 怎么选：systemd、时钟与延迟

交易机器人对 VPS 的要求

用于运行交易机器人的 VPS 主要取决于四点：进程退出后能否自动恢复，系统时钟是否准确，API（应用程序接口）密钥是否难以被窃取，以及进程停止后能否及时获知。对于面向零售用户的机器人，原始运行速度远不如这些因素重要，因为下单链路中最慢的部分是经纪商和网络距离，而不是运行 Python 的主机。

本文是一份工程指南。不构成任何财务建议，也不讨论任何策略。

正常运行时间取决于重启策略，而不是销售页面上的数字

全球每台主机都宣称正常运行时间达到 99.9%。这个数字描述的是虚拟机监控程序，而不是您的机器人。机器人可能因未处理的异常、始终无法重新连接的 websocket，或 OOM（内存不足）killer 而停止运行，而服务器始终在线。因此，真正需要关注的是进程退出后的 10 秒内会发生什么。

将机器人作为 systemd 服务运行，并让 init 系统负责重启。一个 unit 文件只需 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 可禁用速率限制，因此持续崩溃并循环重启的机器人会继续尝试，而不会悄然停止。RestartSec=10 可防止该循环通过反复重新连接向交易所发送过多请求。

先检查文件，确认无误后再启动服务：

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

enable 是能在重启后继续运行的关键，而内核更新意味着需要重启。要确认机器人是否一直在悄然停止运行，请让 systemd 显示重启计数器：

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

一周后的 NRestarts=0 表示机器人运行正常。NRestarts=812 表示您一直在使用整夜反复重新连接的进程进行交易。完整的 unit 文件结构（包括用于每日报告等计划任务的计时器）请参阅 将程序作为 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 密钥放在会被复制的位置

泄露交易所密钥比泄露 SSH 密钥更严重，因为提现权限会让它立即变成资金。两项措施可以覆盖大部分风险。

首先，绝不要为机器人密钥授予提现权限。如果交易所支持，请将密钥绑定到服务器的 IP 地址。这是唯一能让被盗密钥基本失去作用的控制措施。

其次，不要将密钥存放在代码目录中。/opt/tradingbot 中的任何内容迟早都会进入 git 仓库或备份归档。将其放入仅由 systemd 读取的 root 所有文件中：

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 且没有可供登录的主目录的系统账户：

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

这些标志的作用，以及 ProtectSystem=strict 实际能达到的范围，请参阅以非特权用户身份运行服务。服务器的其余基线配置，包括 SSH 密钥和防火墙，应参阅新 VPS 的前 10 分钟。

在您的经纪商发现之前确认服务已停止

systemctl status 表示进程正在运行，但不表示机器人正在执行任何操作。针对失效 websocket 卡在重试循环中的进程，仍然可以通过 systemd 能执行的所有检查。

改用心跳机制。Uptime Kuma 支持推送监控：它要求您的机器人按计划调用一个 URL，并在停止收到调用时发出告警。将调用放在主循环末尾，位于能够证明机器人正常运行的部分之后，例如成功读取市场数据之后。

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

将监控间隔设置为循环耗时的大约两倍，避免正常抖动触发告警。将监控部署在与机器人不同的服务器上，因为监控程序如果与被监控对象一起停止，就无法报告任何信息。设置方法请参阅 使用 Uptime Kuma 进行自托管状态监控。

同时添加磁盘告警。机器人持续写入详细日志，几周内就会占满 root 文件系统。磁盘写满后，停止的是数据库写入，而不是网络调用，因此症状会很异常。journalctl --vacuum-time=14d 和 /etc/systemd/journald.conf 中的 SystemMaxUse= 行可以限制 journal 的大小。

坦诚说：延迟主要不是由您的主机造成的

交易 VPS 产品的市场在这里就不再是技术问题。营销页面会引用亚毫秒级数据，并暗示主机决定了您能否成交。对于几乎所有零售交易机器人来说，事实并非如此。

您的订单会通过公共互联网，从机器人传输到交易所或经纪商端点。该路径主要受物理距离以及您的服务商与对方服务商之间的对等互联影响。位于 Frankfurt 的服务器与 Tokyo 的端点通信时，无论 CPU 多快，往返延迟都大约是 250 milliseconds。然后，经纪商自身的系统还会增加排队、风险检查和速率限制带来的延迟。对于零售账户，这些延迟通常以几十或几百 milliseconds 计。

不要猜测，要进行测量。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 seconds，说明服务器位于错误的大洲，这值得修正。如果 connect 是 0.004 seconds，而 ttfb 是 0.140 seconds，剩余延迟来自经纪商处理，换用主机无法降低这部分延迟。

那么主机什么时候才重要？当您与交易场所共置或通过交叉连接接入，并且需要竞争队列位置时。这属于另一种业务，预算也不同。主机还会在您自己的代码成为瓶颈时产生影响：如果机器人每个 tick 都基于完整历史记录重新计算指标，每次循环可能消耗 200 milliseconds 的 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 key 具有交易权限，但没有提现权限。如果交易所提供 IP allowlist，请启用它。
4. 使用 sudo systemctl kill -s SIGKILL tradingbot 终止进程后，进程会在 RestartSec 内恢复。
5. 有意停止 bot 时，heartbeat monitor 会在一个间隔内向您发送告警。
6. 日志大小受到限制，并且 root 文件系统在 df -h 中保有足够可用空间。

在使用真实资金前，先在交易所的 sandbox 或 paper mode 中完整运行一周。这一周内，上述每一项都会至少失败一次，这正是一周测试的意义。

FAQ

交易机器人需要低延迟服务器或裸机服务器吗？

只有当您在同一交易场所与其他自动化参与者竞争执行速度时才需要。这通常意味着使用托管服务，而不是通用 VPS。对于零售交易机器人，往返延迟主要取决于地理位置和经纪商自身的处理时间。因此，应选择靠近 API 端点的服务器，并先使用 curl 和 mtr 测量，再决定是否为更高性能付费。

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

大多数单策略机器人受网络限制，并且在事件之间处于空闲状态。截至 July 2026，2 vCPU 和 2 GB RAM 足以运行一个跟踪几百个交易品种的 Python 机器人。当您在进程中保存 tick 历史数据或运行本地数据库时，内存可能成为限制因素。因此，应监控 free -h 和 journal，检查 OOM kill 消息，而不要凭感觉估算。

为什么我的交易所 API 因时间戳错误拒绝请求？

服务器时钟已漂移到交易所签名有效窗口之外，通常相差几秒。安装 chrony，确认 chronyc tracking 显示较小的 System time 偏移量以及已同步的闰秒状态，并将机器设置为 UTC，避免夏令时变化导致时间发生偏移。轮换 API key 无法修复时钟问题。

如何防止机器人在夜间停止运行，而我完全不知道？

使用 systemd 和 Restart=always、StartLimitIntervalSec=0 运行机器人。这样发生崩溃循环时，systemd 会继续重试，而不是永久停止。然后添加 heartbeat，让机器人在每次成功完成循环后发送 heartbeat。重启机制用于处理进程崩溃。Heartbeat 用于发现进程仍在运行但已卡住的情况。

我可以在同一台 VPS 上运行机器人和监控程序吗？

可以，但在真正需要监控的那天，监控程序可能会误导您，因为导致机器人停止的中断也会同时使监控程序停止。请将告警系统放在另一台机器上，最好使用不同的提供商或区域。机器人的服务器只用于运行机器人及其日志。