运行交易机器人的VPS需要什么

交易机器人需要 VPS 提供什么

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

本文是一份工程实践指南。其中内容不构成任何金融建议，也不讨论任何交易策略。

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

全球每台主机都宣称拥有 99.9 percent 的正常运行时间。这个数字描述的是 hypervisor，而不是您的 bot。bot 可能因未处理的异常、永不重新连接的 websocket 或 OOM（out of memory）killer 而退出，而服务器始终保持运行。因此，真正有用的问题是：进程退出后的十秒内会发生什么。

将 bot 作为 systemd 服务运行，并由 init 系统负责重启。一个 unit 文件只需六行即可实现这一点。

[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 可禁用速率限制，因此持续崩溃重启的 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 是能在重启后继续生效的部分，而内核更新意味着需要重启。要确认 bot 是否一直在静默退出，请让 systemd 显示重启计数器：

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

一周后显示 NRestarts=0，说明 bot 运行正常。显示 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 仓库或备份归档。应将密钥放入 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 且没有可供登录的主目录的系统账户：

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

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

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

systemctl status 表示进程正在运行，但不表示机器人正在执行任何操作。针对已失效 WebSocket 反复重试的进程，可以通过 systemd 能执行的所有检查。

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

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

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

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

坦诚说：延迟主要不取决于主机

交易 VPS 产品的市场宣传到这里就不再是技术讨论。营销页面会引用亚毫秒级数据，让人以为主机决定了您能否更快成交。对于几乎所有零售交易机器人来说，事实并非如此。

您的订单会通过公网，从机器人传输到交易所或经纪商端点。该路径主要受物理距离，以及您的服务商与对方服务商之间的对等互联影响。无论 CPU 多快，位于 Frankfurt、连接 Tokyo 端点的服务器，往返延迟大约都是 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，内存中保存几百个 symbols 的单策略 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. 日志大小受到限制，并且根文件系统在 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，这样发生崩溃循环时会持续重试，而不会永久停止。然后添加 heartbeat，让机器人在每次循环成功完成时发送一次。重启机制负责处理进程退出的情况。heartbeat 负责发现进程仍在运行但已经卡住的情况。

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

可以，但真正发生故障时，监控系统会误导您，因为导致机器人停止的中断也会同时导致监控系统停止。请将告警系统放在独立机器上，最好使用不同的提供商或区域；机器人的服务器只用于运行机器人和保存其日志。