VPS cho trading bot cần gì để chạy ổn định?

VPS cho trading bot cần gì

Một VPS chạy trading bot được đánh giá trên 4 yếu tố: tiến trình có tự chạy lại sau khi bị dừng không, đồng hồ hệ thống có chính xác không, API key (application programming interface) có khó bị đánh cắp không, và bạn có biết khi bot dừng không. Tốc độ phần cứng không phải yếu tố quan trọng với retail bot, vì phần chậm trong đường đi của lệnh thường nằm ở broker và khoảng cách đến broker, không phải ở máy chủ chạy Python.

Đây là hướng dẫn về kỹ thuật. Nội dung này không phải tư vấn tài chính và không đề cập đến chiến lược nào.

Uptime là kỷ luật khởi động lại, không phải một con số trên trang bán hàng

Mọi máy chủ trên thế giới đều quảng cáo uptime 99.9 phần trăm. Con số đó mô tả hypervisor, không phải bot của bạn. Bot có thể dừng vì exception không được xử lý, websocket không bao giờ reconnect hoặc OOM (out of memory) killer, trong khi server vẫn hoạt động bình thường. Vì vậy, câu hỏi hữu ích là điều gì xảy ra trong 10 giây sau khi process của bạn thoát.

Chạy bot dưới dạng systemd service và để init system quản lý việc restart. Một unit file có thể làm việc này chỉ với 6 dòng.

[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 là dòng nhiều người bỏ sót. Theo mặc định, systemd sẽ bỏ cuộc sau 5 lần restart trong 10 giây và để unit ở trạng thái failed vĩnh viễn. Đây chính là hành vi bạn không muốn xảy ra lúc 03:00. Đặt giá trị này thành 0 sẽ tắt rate limit, nên bot bị crash-loop vẫn tiếp tục thử lại thay vì im lặng dừng. RestartSec=10 ngăn vòng lặp đó liên tục gửi reconnect đến exchange.

Kiểm tra file trước khi tin tưởng cấu hình, rồi start service:

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

enable là phần giúp service tiếp tục hoạt động sau reboot, mà kernel updates đồng nghĩa với reboot. Để biết bot có âm thầm dừng hay không, hãy yêu cầu systemd hiển thị restart counter:

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

NRestarts=0 sau một tuần cho thấy bot hoạt động ổn định. NRestarts=812 nghĩa là bạn đã giao dịch trên một process phải reconnect suốt đêm. Phần giải thích đầy đủ về cấu trúc unit file, bao gồm timer cho các job theo lịch như báo cáo hằng ngày, có trong chạy một chương trình dưới dạng systemd service.

Đặt đồng hồ về UTC và xác nhận đồng bộ hóa

Exchange API ký request bằng timestamp và từ chối các request nằm ngoài một khoảng thời gian cho phép, thường là 5 giây hoặc ít hơn. Đồng hồ bị lệch tạo ra các lỗi trông giống lỗi xác thực, khiến nhiều người xoay vòng key hàng giờ trước khi kiểm tra thời gian. Với các API kiểu Binance, thông báo này có nghĩa đúng như nội dung của nó: Timestamp for this request was 1000ms ahead of the server's time.

Đặt server về UTC. Múi giờ local có thể tạo ra một lần nhảy do daylight saving ở giữa phiên giao dịch.

sudo timedatectl set-timezone UTC
timedatectl

Ubuntu có sẵn systemd-timesyncd, đây là một client SNTP (simple network time protocol). Công cụ này đủ dùng cho log nhưng không phù hợp với các tác vụ cần duy trì độ chính xác trong vài mili giây, vì nó chỉ poll một server và không liên tục điều chỉnh đồng hồ. Thay vào đó, dùng chrony:

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

Dòng cần đọc từ chronyc tracking là System time, ví dụ System time : 0.000031415 seconds fast of NTP time. Giá trị dưới vài mili giây là bình thường. Nếu kết quả là Leap status : Not synchronised, chrony chưa kết nối được với server, thường là do UDP 123 outbound bị chặn. Chờ một phút rồi kiểm tra lại trước khi chỉnh firewall.

Để API key ngoài những nơi bạn thường sao chép

Key của sàn bị lộ nguy hiểm hơn key SSH bị lộ, vì quyền rút tiền có thể biến nó thành tiền ngay lập tức. Hai thói quen giúp kiểm soát phần lớn rủi ro.

Trước tiên, không bao giờ cấp quyền rút tiền cho key của bot. Nếu sàn hỗ trợ, hãy giới hạn key chỉ được dùng từ địa chỉ IP của server. Đây là biện pháp kiểm soát quan trọng nhất, khiến key bị đánh cắp gần như vô dụng.

Tiếp theo, không lưu secret trong thư mục code. Mọi thứ nằm trong /opt/tradingbot sớm muộn cũng sẽ lọt vào git repository hoặc backup archive. Hãy đặt secret trong một file do root sở hữu để chỉ systemd đọc được:

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

File chứa các dòng KEY=value thuần, không có dấu ngoặc kép và không có export. Mode 640 với group bot cho phép service user đọc file, còn mọi user khác thì không. Xác minh bằng sudo -u bot cat /etc/tradingbot/api.env, sau đó thử bằng một user khác; lệnh này phải fail với Permission denied.

Bot cũng không nên chạy bằng root hoặc user dùng để đăng nhập. Hãy tạo một system account không có shell và không có home directory để đăng nhập:

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

Phần giải thích cho từng flag trên và giới hạn thực tế của ProtectSystem=strict có trong chạy service bằng user không có quyền đặc biệt. Các thiết lập cơ bản còn lại của server, gồm SSH key và firewall, có trong 10 phút đầu tiên trên một VPS mới.

Phát hiện bot ngừng hoạt động trước khi broker phát hiện

systemctl status cho biết tiến trình đang chạy. Nó không cho biết bot có đang thực hiện công việc hay không. Một tiến trình bị kẹt trong vòng lặp retry khi kết nối đến websocket đã ngừng hoạt động vẫn vượt qua mọi kiểm tra mà systemd có thể thực hiện.

Thay vào đó, hãy dùng heartbeat. Uptime Kuma có push monitor: nó yêu cầu bot gọi một URL theo lịch, rồi cảnh báo khi không còn nhận được lệnh gọi. Đặt lệnh gọi ở cuối vòng lặp chính, sau phần xác nhận bot vẫn hoạt động, chẳng hạn như đọc dữ liệu thị trường thành công.

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

Đặt interval của monitor khoảng gấp đôi thời gian chạy một vòng lặp để jitter thông thường không tạo cảnh báo giả. Chạy monitor trên server khác với bot, vì monitor sẽ ngừng hoạt động cùng với đối tượng mà nó theo dõi và không thể báo cáo gì. Hướng dẫn thiết lập có tại giám sát trạng thái tự host bằng Uptime Kuma.

Thêm cả cảnh báo dung lượng disk. Bot ghi log chi tiết có thể làm đầy root filesystem trong vài tuần. Khi disk đầy, thao tác ghi database sẽ dừng trước, không phải network call, nên triệu chứng có thể khó hiểu. journalctl --vacuum-time=14d và một dòng SystemMaxUse= trong /etc/systemd/journald.conf giúp giới hạn kích thước journal.

Phần thực tế: độ trễ chủ yếu không nằm ở máy chủ của bạn

Đây là điểm mà thị trường VPS cho giao dịch ngừng mang tính kỹ thuật. Các trang marketing đưa ra con số dưới một mili giây và ám chỉ rằng máy chủ là yếu tố cản trở bạn khớp lệnh. Với gần như mọi bot bán lẻ, điều đó không đúng.

Lệnh của bạn đi từ bot đến endpoint của sàn hoặc broker qua Internet công cộng. Đường truyền đó bị chi phối chủ yếu bởi khoảng cách vật lý và quan hệ peering giữa nhà cung cấp của bạn với nhà cung cấp của họ. Một server ở Frankfurt giao tiếp với endpoint ở Tokyo sẽ mất khoảng 250 mili giây cho một vòng khứ hồi, bất kể CPU nhanh đến đâu. Sau đó, hệ thống của broker còn thêm thời gian xếp hàng, kiểm tra rủi ro và áp dụng rate limit. Với tài khoản bán lẻ, các khoản này thường được tính bằng hàng chục hoặc hàng trăm mili giây.

Hãy đo thay vì đoán. curl báo cáo thời gian kết nối và thời gian nhận byte đầu tiên của một endpoint thực:

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

Chạy lệnh đó trên server dự kiến sử dụng trước khi quyết định. Nếu connect là 0.180 giây, bạn đang ở sai châu lục và nên khắc phục vị trí này. Nếu connect là 0.004 giây còn ttfb là 0.140 giây, phần độ trễ còn lại nằm ở quá trình xử lý của broker. Việc đổi host sẽ không cải thiện được phần này.

Vậy khi nào host mới quan trọng? Đó là khi bạn đặt server cùng trung tâm dữ liệu hoặc kết nối trực tiếp với venue và cạnh tranh về vị trí trong hàng đợi. Đây là một mô hình kinh doanh khác với ngân sách khác. Host cũng quan trọng khi chính code của bạn là nút thắt. Một bot tính toán lại indicator trên toàn bộ lịch sử ở mỗi tick có thể dùng 200 mili giây CPU cho mỗi vòng lặp. Đây là độ trễ thực tế mà bạn có thể kiểm soát mà không tốn thêm chi phí. Hãy profile vòng lặp trước khi tìm server nhanh hơn.

Những yếu tố thực sự quan trọng khi chọn host là vị trí địa lý, mạng ổn định và dung lượng bộ nhớ đủ lớn để OOM killer không bao giờ phải can thiệp. Tính đến tháng 7 năm 2026, một bot Python chạy một chiến lược với vài trăm symbol trong bộ nhớ hoạt động thoải mái với 2 GB RAM và 2 vCPU. Hãy tăng bộ nhớ nếu bạn lưu lịch sử tick trong một database cục bộ.

Danh sách kiểm tra ngắn trước khi chạy production

1. systemctl is-enabled tradingbot in ra enabled và service vẫn hoạt động sau sudo reboot.
2. chronyc tracking báo độ lệch giờ hệ thống dưới vài mili giây.
3. API key có quyền giao dịch, không có quyền rút tiền và có IP allowlist nếu sàn hỗ trợ.
4. Dùng sudo systemctl kill -s SIGKILL tradingbot để dừng process thì process khởi động lại trong vòng RestartSec.
5. Heartbeat monitor gửi cảnh báo cho bạn trong vòng một chu kỳ khi bạn chủ động dừng bot.
6. Log có giới hạn kích thước và filesystem root còn đủ dung lượng trống trong df -h.

Chạy toàn bộ hệ thống trong sandbox của sàn hoặc ở paper mode trong một tuần trước khi dùng tiền thật. Mỗi mục ở trên sẽ fail ít nhất một lần trong tuần đó. Đó chính là mục đích của tuần kiểm thử này.

FAQ

Does a trading bot need a low-latency or bare metal server?

Only if you are competing on execution speed against other automated participants at the same venue, which normally means colocation rather than a general purpose VPS. For a retail bot the round trip is dominated by geography and by the broker's own processing, so pick a server close to the API endpoint and measure with curl and mtr before paying for anything faster.

How much RAM and CPU does a trading bot need?

Most single-strategy bots are network-bound and idle between events. As of July 2026, 2 vCPU and 2 GB of RAM handle a Python bot tracking a few hundred instruments. Memory becomes the constraint when you hold tick history in process or run a local database, so watch free -h and the journal for OOM kill messages rather than guessing.

Why does my exchange API reject requests with a timestamp error?

The server clock has drifted outside the exchange's signing window, usually a few seconds. Install chrony, confirm chronyc tracking shows a small System time offset and a synchronised leap status, and set the machine to UTC so a daylight saving change never shifts it. Rotating the API key does not fix a clock problem.

How do I stop my bot from dying overnight without me knowing?

Run it under systemd with Restart=always and StartLimitIntervalSec=0 so a crash loop keeps retrying instead of stopping permanently, then add a heartbeat that the bot sends at the end of each successful loop. The restart handles the process. The heartbeat catches the case where the process is alive but stuck.

Can I run the bot and my monitoring on the same VPS?

You can, and the monitoring will lie to you the day it matters, because an outage that takes down the bot takes the monitor with it. Keep the alerting on a separate machine, ideally with a different provider or region, and use the bot's server only for the bot and its logs.