VPS Terbaik untuk Trading Bot: Apa yang Penting?

Keperluan VPS untuk bot dagangan

VPS untuk bot dagangan dinilai berdasarkan empat perkara: adakah proses akan bermula semula selepas terhenti, adakah jam sistem tepat, adakah kunci API (application programming interface) sukar dicuri, dan adakah anda mendapat makluman apabila bot berhenti berfungsi. Kelajuan mentah berada di kedudukan rendah dalam senarai tersebut bagi bot runcit, kerana bahagian yang perlahan dalam laluan pesanan anda ialah broker anda dan jarak ke broker tersebut, bukannya hos yang menjalankan Python anda.

Ini ialah panduan kejuruteraan. Tiada apa-apa di sini merupakan nasihat kewangan, dan tiada strategi dibincangkan.

Uptime ialah disiplin mulakan semula, bukan sekadar angka pada halaman jualan

Setiap hos di dunia mengiklankan 99.9 peratus uptime. Angka tersebut menggambarkan hypervisor, bukan bot anda. Bot mati akibat pengecualian yang tidak dikendalikan, websocket yang tidak pernah bersambung semula, atau OOM (out of memory) killer, manakala pelayan kekal hidup sepanjang masa. Jadi, soalan yang berguna ialah apa yang berlaku dalam sepuluh saat selepas proses anda tamat.

Jalankan bot sebagai servis systemd dan biarkan sistem init menguruskan mulakan semula. Fail unit melakukan ini dalam enam baris.

[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 ialah baris yang sering terlepas pandang oleh pengguna. Secara lalai, systemd akan berhenti selepas 5 kali mulakan semula dalam tempoh 10 saat dan membiarkan unit dalam keadaan failed selama-lamanya, iaitu tingkah laku yang tidak anda inginkan pada pukul 03:00. Menetapkannya kepada 0 akan melumpuhkan had kadar, supaya bot yang mengalami gelung ranap (crash-loop) terus mencuba dan tidak senyap. RestartSec=10 menghentikan gelung tersebut daripada membanjiri bursa dengan permintaan sambungan semula.

Semak fail tersebut sebelum anda mempercayainya, kemudian mulakannya:

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

enable ialah bahagian yang bertahan selepas but semula, dan kemas kini kernel bermakna but semula. Untuk melihat sama ada bot telah mati secara senyap, minta systemd menunjukkan pembilang mulakan semula:

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

NRestarts=0 selepas seminggu ialah bot yang sihat. NRestarts=812 bermakna anda telah berdagang menggunakan proses yang bersambung semula sepanjang malam. Anatomi penuh fail unit, termasuk pemasa untuk tugasan berjadual seperti laporan harian, diliputi dalam menjalankan program sebagai servis systemd.

Tetapkan jam kepada UTC dan sahkan penyegerakannya

API pertukaran menandatangani permintaan dengan cap masa dan menolak sebarang permintaan di luar tetingkap masa, biasanya 5 saat atau kurang. Jam yang hanyut menghasilkan ralat yang kelihatan seperti kegagalan pengesahan, menyebabkan pengguna menukar kunci selama berjam-jam sebelum memeriksa masa. Pada API gaya Binance, mesejnya adalah literal: Timestamp for this request was 1000ms ahead of the server's time.

Tetapkan pelayan kepada UTC. Zon masa tempatan memperkenalkan lonjakan penjimatan siang (daylight saving) yang akan berlaku di tengah-tengah sesi dagangan.

sudo timedatectl set-timezone UTC
timedatectl

Ubuntu membekalkan systemd-timesyncd, iaitu klien SNTP (simple network time protocol). Ia memadai untuk log tetapi lemah untuk sebarang keperluan yang perlu kekal dalam julat beberapa milisaat, kerana ia meninjau satu pelayan sahaja dan tidak mendisiplinkan jam secara berterusan. Gunakan chrony sebaliknya:

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

Baris untuk dibaca daripada chronyc tracking ialah System time, contohnya System time : 0.000031415 seconds fast of NTP time. Sebarang nilai di bawah beberapa milisaat adalah sihat. Jika ia membaca Leap status : Not synchronised, chrony belum mencapai pelayan, biasanya kerana trafik keluar UDP 123 disekat. Tunggu seminit, kemudian periksa semula sebelum mengubah peraturan firewall.

Pastikan kunci API tidak berada di tempat yang anda salin

Kunci pertukaran (exchange key) yang bocor adalah lebih buruk daripada kunci SSH yang bocor, kerana kebenaran pengeluaran membolehkan dana dicuri dengan serta-merta. Dua tabiat dapat mengurangkan kebanyakan risiko ini.

Pertama, jangan sekali-kali memberikan kebenaran pengeluaran kepada kunci bot, dan jika pertukaran tersebut menyokongnya, ikat kunci tersebut pada alamat IP pelayan anda. Ini adalah satu-satunya kawalan yang menjadikan kunci yang dicuri hampir tidak berguna.

Kedua, simpan rahsia tersebut di luar direktori kod. Apa-apa sahaja di dalam /opt/tradingbot akan berakhir dalam repositori git atau arkib sandaran lambat laun. Letakkannya dalam fail milik root yang hanya dibaca oleh 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

Fail tersebut mengandungi baris KEY=value biasa tanpa tanda petikan dan tanpa export. Mod 640 dengan kumpulan bot bermakna pengguna servis boleh membacanya dan tiada orang lain yang boleh. Sahkan dengan sudo -u bot cat /etc/tradingbot/api.env dan kemudian dengan mana-mana pengguna lain, di mana ia mesti gagal dengan Permission denied.

Bot itu sendiri tidak sepatutnya berjalan sebagai root atau sebagai pengguna log masuk anda. Cipta akaun sistem tanpa shell dan tanpa direktori rumah untuk log masuk:

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

Sebab di sebalik setiap flag tersebut, dan sejauh mana ProtectSystem=strict sebenarnya berfungsi, terdapat dalam menjalankan servis sebagai pengguna tanpa keistimewaan. Selebihnya garis dasar pelayan, kunci SSH dan firewall, terkandung dalam sepuluh minit pertama pada VPS baharu.

Ketahui servis terhenti sebelum broker anda mengetahuinya

systemctl status menyatakan bahawa proses sedang berjalan. Ia tidak menyatakan bahawa bot sedang melakukan sebarang tugasan. Proses yang terperangkap dalam gelung cuba semula (retry loop) terhadap websocket yang mati akan melepasi setiap pemeriksaan yang boleh dilakukan oleh systemd.

Gunakan heartbeat sebagai ganti. Uptime Kuma mempunyai push monitor: ia menjangkakan bot anda memanggil URL mengikut jadual, dan akan memberi amaran apabila panggilan tersebut berhenti diterima. Letakkan panggilan tersebut di hujung gelung utama anda, selepas bahagian yang membuktikan bot masih aktif, seperti bacaan data pasaran yang berjaya.

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

Tetapkan selang monitor kepada kira-kira dua kali ganda masa gelung anda supaya jitter biasa tidak mencetuskan amaran. Jalankan monitor pada pelayan yang berbeza daripada bot, kerana monitor yang mati bersama-sama dengan perkara yang dipantaunya tidak akan melaporkan apa-apa. Persediaan ini diterangkan dalam pemantauan status layan diri dengan Uptime Kuma.

Tambah amaran cakera juga. Bot yang menulis log secara verbose akan memenuhi sistem fail root dalam masa beberapa minggu, dan cakera yang penuh akan menghentikan penulisan pangkalan data, bukan panggilan rangkaian, jadi simptomnya akan menjadi pelik. journalctl --vacuum-time=14d dan baris SystemMaxUse= dalam /etc/systemd/journald.conf akan memastikan saiz journal terkawal.

Bahagian yang jujur: latensi kebanyakannya bukan berpunca daripada hos anda

Di sinilah pasaran produk VPS dagangan berhenti menjadi teknikal. Halaman pemasaran memetik angka sub-milisaat dan membayangkan hos adalah penghalang antara anda dan pelaksanaan pesanan. Bagi hampir setiap bot runcit, ia bukanlah puncanya.

Pesanan anda bergerak daripada bot ke endpoint bursa atau broker melalui internet awam. Laluan tersebut didominasi oleh jarak fizikal dan peering antara penyedia anda dengan penyedia mereka. Pelayan di Frankfurt yang berhubung dengan endpoint di Tokyo akan menanggung kira-kira 250 milisaat perjalanan pergi-balik tidak kira betapa laju CPU tersebut. Kemudian, sistem broker itu sendiri menambah baris gilir, semakan risiko dan had kadar mereka, yang bagi akaun runcit biasanya diukur dalam puluhan atau ratusan milisaat.

Ukur latensi tersebut dan jangan sekadar meneka. curl melaporkan masa sambungan dan bait pertama untuk endpoint sebenar:

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

Jalankan arahan itu daripada pelayan calon sebelum anda membuat keputusan. Jika connect ialah 0.180 saat, anda berada di benua yang salah, dan itu perkara yang perlu diperbaiki. Jika connect ialah 0.004 saat dan ttfb ialah 0.140 saat, baki kelewatan tersebut adalah pemprosesan broker, dan tiada perubahan hos yang akan menyelesaikannya.

Jadi, bilakah hos itu penting? Apabila anda diletakkan bersama (colocated) atau disambungkan secara silang (cross-connected) ke tempat dagangan dan bersaing untuk kedudukan baris gilir, yang merupakan perniagaan berbeza dengan bajet berbeza. Begitu juga apabila kod anda sendiri menjadi bottleneck: bot yang mengira semula indikator sepanjang sejarah penuh bagi setiap tick boleh menghabiskan 200 milisaat CPU bagi setiap gelung, yang merupakan latensi sebenar yang anda boleh kawal secara percuma. Buat profil gelung tersebut sebelum anda mencari pelayan yang lebih laju.

Perkara yang penting pada hos yang anda pilih ialah geografi, rangkaian yang stabil dan memori yang mencukupi supaya OOM killer tidak perlu bertindak. Setakat Julai 2026, bot Python strategi tunggal dengan beberapa ratus simbol dalam memori berjalan dengan selesa dalam 2 GB RAM dan 2 vCPU. Tambah memori jika anda menyimpan sejarah tick dalam pangkalan data tempatan.

Senarai semak ringkas pra-pelancaran

1. systemctl is-enabled tradingbot mencetak enabled, dan servis bertahan selepas sudo reboot.
2. chronyc tracking melaporkan offset masa sistem di bawah beberapa milisaat.
3. Kunci API mempunyai kebenaran dagangan, tiada kebenaran pengeluaran, dan senarai putih IP jika bursa menyediakannya.
4. Mematikan proses dengan sudo systemctl kill -s SIGKILL tradingbot memulihkannya dalam tempoh RestartSec.
5. Pemantau degupan jantung (heartbeat monitor) menghantar makluman kepada anda dalam satu selang masa apabila anda menghentikan bot secara sengaja.
6. Log adalah terhad dan sistem fail root mempunyai ruang simpanan dalam df -h.

Jalankan keseluruhan sistem dalam sandbox bursa atau dalam mod kertas (paper mode) selama seminggu sebelum menggunakan dana sebenar. Setiap perkara di atas akan gagal sekurang-kurangnya sekali dalam minggu tersebut, dan itulah tujuan minggu percubaan itu.

FAQ

Adakah bot dagangan memerlukan pelayan latensi rendah atau bare metal?

Hanya jika anda bersaing dari segi kelajuan pelaksanaan dengan peserta automatik lain di bursa yang sama, yang biasanya bermaksud kolokasi dan bukannya VPS tujuan am. Bagi bot runcit, perjalanan pergi balik (round trip) lebih dipengaruhi oleh geografi dan pemprosesan broker itu sendiri. Jadi, pilih pelayan yang dekat dengan endpoint API dan buat pengukuran menggunakan curl serta mtr sebelum membayar untuk spesifikasi yang lebih pantas.

Berapakah jumlah RAM dan CPU yang diperlukan oleh bot dagangan?

Kebanyakan bot strategi tunggal terhad oleh rangkaian (network-bound) dan melahu di antara peristiwa. Setakat Julai 2026, 2 vCPU dan 2 GB RAM sudah memadai untuk mengendalikan bot Python yang menjejaki beberapa ratus instrumen. Memori menjadi kekangan apabila anda menyimpan sejarah tick dalam proses atau menjalankan pangkalan data tempatan. Oleh itu, pantau free -h dan jurnal untuk mesej OOM kill daripada membuat andaian.

Mengapakah API bursa saya menolak permintaan dengan ralat cap masa (timestamp error)?

Jam pelayan telah terpesong di luar tetingkap penandatanganan bursa, biasanya dalam beberapa saat. Pasang chrony, sahkan chronyc tracking menunjukkan offset System time yang kecil serta status leap yang disegerakkan, dan tetapkan mesin kepada UTC supaya perubahan waktu penjimatan siang (daylight saving) tidak mengubahnya. Menukar API key tidak akan menyelesaikan masalah jam.

Bagaimanakah cara untuk menghalang bot saya daripada terhenti pada waktu malam tanpa pengetahuan saya?

Jalankannya di bawah systemd dengan Restart=always dan StartLimitIntervalSec=0 supaya gelung ranap (crash loop) terus mencuba semula dan bukannya berhenti secara kekal. Kemudian, tambah denyut nadi (heartbeat) yang dihantar oleh bot pada penghujung setiap gelung yang berjaya. Proses restart akan mengendalikan proses tersebut. Denyut nadi akan mengesan situasi di mana proses masih hidup tetapi tersangkut.

Bolehkah saya menjalankan bot dan pemantauan pada VPS yang sama?

Anda boleh, tetapi pemantauan tersebut akan memberikan maklumat palsu pada hari yang kritikal, kerana gangguan yang menjatuhkan bot akan turut menjatuhkan sistem pemantau. Pastikan amaran berada pada mesin yang berasingan, sebaik-baiknya dengan penyedia atau wilayah yang berbeza, dan gunakan pelayan bot hanya untuk bot serta lognya sahaja.