Hosting Minecraft 8 phút đọc

VPS của bạn cần gì để "cất cánh"? CyberPanel và những tính năng không thể bỏ qua

Tác giả Thang Le Minh Đội ngũ hỗ trợ PIKAMC

11 giờ đêm, mình SSH vào con VPS 2GB đang chạy CyberPanel để upgrade panel. Việc tưởng như routine, làm cả chục lần rồi. Script chạy ro ro, log báo từng component cài xong, và rồi dòng cuối cùng hiện ra: "Seems something wrong with upgrade, please check..."

Tim rớt một nhịp. Trên con VPS đó có ba site đang chạy thật.

Chuyện đêm đó kết thúc thế nào, mình để dành cuối bài — vì nó dính tới một cơ chế khá hay mà ít ai để ý. Còn giờ đi từ đầu: CyberPanel là gì, cài sao cho đúng, và những cái "mặc định" nào bạn nên sờ tới trước khi tin tưởng giao VPS cho nó.

CyberPanel là gì mà dân VPS nhắc hoài?

Nó là control panel miễn phí chạy trên nền OpenLiteSpeed — bạn dùng full tính năng, không giới hạn số site. Muốn lên LiteSpeed Enterprise thì mua bundle, đắt hơn license LiteSpeed đúng 1 đô. Kèm theo là DNS server riêng (PowerDNS), mail (Postfix/Dovecot), FTP, deploy Docker, và cái đáng tiền nhất: LSCache cho WordPress.

Trong một thread review trên LowEndTalk mà mình hay trích lại, có một câu tóm gọn rất trúng: "It's fast, since it uses OLS/LSWS. Especially with Wordpress if you use LSCache plugin... I wouldn't trust it to sell hosting to clients." Nhanh thật, nhưng để bán hosting cho khách thì người ta còn lăn tăn. Mình thấy đánh giá đó công bằng.

Cũng trong thread đó, có người khen kiến trúc phân quyền của nó: mỗi site bị nhốt vào một user riêng, permission riêng, môi trường bị giới hạn. Và một điểm ăn tiền so với DirectAdmin hay aaPanel: CyberPanel là panel duy nhất cho bạn dùng thẳng GUI của LiteSpeed thay vì phải mò vào file XML mà sửa tay.

Cyberpanel là gì? Lệnh Cài Đặt Cyberpanel trên CentOS/Ubuntu

Cài đặt CyberPanel trên VPS: chuẩn bị gì trước khi gõ lệnh?

Ba thứ bắt buộc: OS phải là bản cài mới tinh (fresh install), RAM từ 1024MB trở lên, disk trống 10GB. Chỉ chạy x86_64. Danh sách OS hỗ trợ khá dài — Ubuntu 20.04/22.04/24.04, Debian 11/12/13, AlmaLinux 8/9/10, Rocky, RHEL — nhưng nguyên tắc "OS sạch" thì không du di được.

Một thứ nhỏ mà hay vấp: phải SSH bằng root thật. Tài liệu chính thức ghi thẳng "Sudo will not work". Update OS xong xuôi rồi mới chạy:

sh <(curl https://cyberpanel.net/install.sh || wget -O - https://cyberpanel.net/install.sh)

Trong lúc cài nó hỏi vài câu: chọn 1 để lấy OpenLiteSpeed free, Full Service gõ Y (cài luôn PowerDNS, Postfix, Pure-FTPd), Remote MySQL gõ N trừ khi bạn dùng database ngoài, Redis/Memcached gõ Y. Chờ chừng 5-10 phút tùy máy.

Cài xong, panel nằm ở port 8090, còn webadmin console của OpenLiteSpeed ở port 7080. Nhớ hai con số này, lát nữa còn dùng.

Nếu cài fail? Đừng đoán mò. Mọi thứ nằm trong /var/log/installLogs.txt. Hồi tháng 2 năm nay mình đọc được một case trên forum CyberPanel: một bạn cài đúng lệnh trên nhưng dừng giữa chừng với lỗi:

[02.13.2026_20-39-17] [ERROR] We are not able to run /usr/local/CyberPanel/bin/python manage.py migrate return code: 1. Fatal error, see /var/log/installLogs.txt for full details.
Oops, something went wrong...

Nhìn log theo mốc % thì cả quá trình chạy được khoảng 6 phút, qua hết LiteSpeed, MySQL, tới bước Django migrate mới gãy. Bài học: log cài đặt có ghi tiến độ từng bước, đọc nó trước khi đi hỏi.

Mặc định 100.000 connection cho VPS giá rẻ. Nghe đã thấy sai.

Đây là case mình đọc trên forum CyberPanel và nhớ mãi, vì nó lật ngược định kiến "OpenLiteSpeed lúc nào cũng nhanh". Một bạn chạy load test so sánh VPS 5 đô chạy Nginx với VPS chạy CyberPanel + OLS. Kết quả ban đầu khá thảm:

  • 250 clients/giây: OLS trả trung bình 261ms — ổn.
  • 500 clients/giây: sập luôn, avg 4992ms, 42% lỗi.
  • 1000 clients/giây: crash, restart mấy lần không hoàn thành nổi test. Nâng lên cả LiteSpeed Enterprise vẫn 42% lỗi.

Bạn đó hỏi nguyên văn: "A 20$ VPS running Cyberpanel with Litespeed Enterprise still can't beat 5$ Nginx VPS with Gridpane. Is it true or there is something wrong with Cyberpanel?"

Có gì đó sai thật. Nguyên nhân tìm ra: CyberPanel thời điểm đó đặt mặc định Max Connections = 100000 và bật Smart Keep Alive — con số cho server xịn, không phải cho box 1 vCPU. Server nhận connection nhiều gấp trăm lần sức nó gánh nổi, nên thay vì từ chối bớt, nó ôm hết rồi chết chung.

Bạn tự kiểm tra được ngay: mở webadmin console port 7080, vào phần Tuning của server config mà xem giá trị Max Connections trên máy bạn đang là bao nhiêu. Config sau khi sửa trong case đó, trên VPS Vultr 5 đô:

Max Connections: 2000
Max SSL Connections: 2000
Keep Alive Timeout: 3
Smart Keep Alive: OFF

Kết quả sau fix, nguyên văn: "my box can handle 1000 clients per sec test without problem. It even outperform GP Nginx in avg response time". Cùng phần cứng, cùng phần mềm — chỉ đổi 4 giá trị. Về sau CyberPanel đã sửa default này trong một commit trên GitHub, nhưng máy cài từ trước thì không tự đổi đâu, bạn vẫn nên tự kiểm.

Nói thật: với blog vài trăm khách một ngày, đừng phức tạp hóa chuyện tuning. Nhưng nếu định chạy gì có traffic dồn cục — landing page chạy ads, site bán vé — thì đây là mục đáng 10 phút của bạn nhất bài này.

503 à? Bình tĩnh, đừng cài lại vội

Lỗi kinh điển: vào https://IP:8090 thấy 503 Service Unavailable. Bản CyberPanel mới chạy panel qua service lscpd (bản cũ là gunicorn), nên bước một luôn là:

systemctl status lscpd
systemctl start lscpd

Chưa hết thì làm theo quy trình được confirm "This solution worked for me" trên community — cài lại đống dependency Python của panel:

source /usr/local/CyberCP/bin/activate
pip install --ignore-installed -r /usr/local/CyberCP/requirments.txt
deactivate
virtualenv --system-site-packages /usr/local/CyberCP
systemctl restart lscpd

À, không phải mình gõ sai đâu — file trong CyberPanel viết sai chính tả thành requirments.txt thật. Gõ "requirements" đúng chuẩn là lệnh fail ngay.

Log của web server nằm trong /usr/local/lsws/logs/, grep chữ ERROR mà lần. Một dấu hiệu hay để định vị vấn đề: nếu mail vẫn gửi nhận bình thường trong lúc panel 503, tức là chỉ mỗi phần web của panel chết — Postfix/Dovecot chạy độc lập, không dính gì tới nó.

Update panel: đợi một tuần rồi hãy bấm

Lời khuyên mình tâm đắc nhất từ thread LowEndTalk kia, nguyên văn: "I'd just advise not updating to any new version releases for a week or so after they come out because there are usually at least a few bugs that are going to pop up." Cũng thread đó, một admin dùng CyberPanel 3 năm trên hàng chục server kể rằng 4 trên 5 lần update panel của bạn ấy kết thúc bằng lỗi 500. Con số của một người, không phải thống kê ngành, nhưng đủ để mình không bao giờ update ngày đầu.

Và tuyệt đối đừng nâng cấp OS tại chỗ khi đã cài panel. Trên GitHub có issue một bạn nâng Ubuntu 22.04 lên 24.04, xong panel trả 503 vĩnh viễn — thời điểm đó maintainer trả lời thẳng Ubuntu 24 chưa được hỗ trợ. Câu trả lời chính thức trên forum cũng vậy: muốn đổi OS thì cài lại từ OS sạch rồi migrate.

À, một cái nhiều bạn hay quên: snapshot VPS trước khi upgrade. Panel nào cũng vậy, không riêng CyberPanel. Backup đã. Rồi muốn làm gì thì làm.

Rồi, quay lại cái đêm "Seems something wrong..."

Đêm đó mình mất gần 40 phút hoảng loạn. Nhưng việc đầu tiên mình làm đúng: thay vì chạy lại upgrade, mình mở trình duyệt vào https://IP:8090. Panel... login được bình thường. Ba site vẫn chạy. Vậy script kêu ca cái gì?

Mãi sau mình mới thấy trong repo CyberPanel trên GitHub có hẳn một tài liệu support về đúng vụ này. Cơ chế thế này: script upgrade bản cũ kiểm tra panel sống hay chết bằng cách tìm chuỗi literal "200 OK" trong response. Nghe hợp lý? Không. Panel có thể trả redirect, trả trang đòi đăng nhập, hoặc — hay nhất — nói chuyện qua HTTP/2, mà status line HTTP/2 chỉ có số, không kèm chữ "OK". Bạn tự thử được: chạy curl -I vào một site HTTP/2 bất kỳ mà xem, dòng đầu là "HTTP/2 200" trần trụi. Panel sống nhăn răng, script không tìm thấy chuỗi nó muốn, thế là in lỗi.

Cách verify chuẩn theo chính doc đó:

curl -k -L -s -o /dev/null -w "%{http_code}\n" https://127.0.0.1:8090/
grep -i "All components successfully installed" /var/log/cyberpanel_upgrade_debug.log

Status trả về 200, 302, 401 hay 403 — panel sống, message cuối là báo động giả. Còn nếu ra 000 hoặc connection refused, và ss -ltnp | grep ':8090' không thấy gì đang listen, lúc đó mới thật sự có chuyện.

Con VPS của mình đêm ấy: curl trả 200, log debug có đủ dòng "successfully installed". Upgrade thành công từ đầu. Mình đi ngủ lúc 1 giờ sáng, hơi cay, nhưng học được một bài: đừng tin dòng thông báo cuối cùng — tin cái bạn tự kiểm chứng được. Cách kiểm này không tuyệt đối hoàn hảo cho mọi tình huống, nhưng nó cứu bạn khỏi 90% các cú "tưởng chết mà hóa ra đang sống". Với CyberPanel, và thật ra với mọi thứ bạn chạy trên VPS.