Kiểm tra ping VPS cho đúng cần nhiều hơn một lệnh ping từ laptop. Bạn cần số mẫu đủ lớn, cái nhìn về tuyến đường mà gói tin đi qua, và thời gian thực tế của một yêu cầu hoàn chỉnh. Bài này hướng dẫn các lệnh trên Windows, macOS và Linux, giải thích cách đọc kết quả mà không bị đánh lừa bởi những "báo động giả" thường gặp, và gợi ý một cách rẻ để so sánh các vị trí trước khi cam kết.
Nếu chưa có danh sách vị trí ứng viên, hãy đọc trước bài chọn vị trí VPS theo độ trễ, và xem hướng dẫn các vị trí VPS để biết đầy đủ các khu vực.
Tạo máy thử ở mỗi vị trí ứng viên
Bạn cần một địa chỉ IP để đo. Máy chủ Cloudj có thể tính tiền theo giờ, nên cách đơn giản nhất là triển khai gói nhỏ nhất ở từng vị trí đang cân nhắc, chạy các bài đo bên dưới trong một ngày rồi xóa những máy không giữ lại. Máy theo giờ bị tính phí suốt thời gian còn tồn tại, dù đang chạy hay đã tắt, nên phải xóa máy thì mới dừng tính tiền.
Hãy chọn image Linux như Ubuntu hoặc Debian, thêm SSH key ngay lúc triển khai (xem cách tạo SSH key cho VPS) và ghi lại IP public của từng máy. Trong các lệnh dưới đây, thay 203.0.113.10 bằng IP máy chủ của bạn.
Kiểm tra ping VPS bằng lệnh ping
ping gửi gói ICMP echo và báo thời gian khứ hồi của từng phản hồi. Hãy gửi đủ nhiều gói để thấy được độ dao động, đừng chỉ dừng ở bốn gói mặc định của Windows.
Trên Linux và macOS:
ping -c 50 203.0.113.10Trên Windows (Command Prompt hoặc PowerShell):
ping -n 50 203.0.113.10Cuối cùng bạn sẽ có một dòng tổng kết. Linux và macOS hiển thị min/avg/max/mdev (macOS ghi giá trị cuối là stddev), còn Windows hiển thị Minimum, Maximum và Average. Cách đọc:
- Giá trị trung bình hoặc trung vị là độ trễ thường gặp.
- Khoảng cách giữa min và max cho biết jitter. Kết nối ổn định có khoảng cách nhỏ; khoảng cách lớn nghĩa là có hàng đợi đang đầy ở đâu đó.
- Mất gói lớn hơn 0 ở đích cần được xem kỹ hơn bằng
mtr.
Một số mạng hạ ưu tiên hoặc chặn ICMP. Nếu ping không có phản hồi nào nhưng SSH vẫn vào được, nghĩa là ICMP bị lọc chứ máy chủ không hề chết.
Xem tuyến đường bằng mtr
mtr kết hợp traceroute và ping: nó gửi gói thăm dò liên tục và báo tỷ lệ mất gói, độ trễ ở từng hop. Đây là công cụ tốt nhất để biết độ trễ phát sinh ở đâu.
Cài trên Ubuntu hoặc Debian:
sudo apt update
sudo apt install mtr-tinyTrên macOS với Homebrew:
brew install mtrChạy chế độ báo cáo với 100 vòng, hiển thị tên host đầy đủ và số AS:
sudo mtr -rwz -c 100 203.0.113.10Trên Linux, mtr thường chạy được không cần sudo; bản Homebrew trên macOS thì cần. Nếu ICMP bị lọc trên đường đi, hãy dùng gói thăm dò TCP tới một cổng đang mở trên máy chủ, ví dụ cổng SSH:
sudo mtr -rwz -c 100 -T -P 22 203.0.113.10Windows không có sẵn mtr. Bạn dùng lệnh pathping có sẵn, lệnh này dò tuyến rồi đo từng hop trong vài phút, hoặc tracert để xem nhanh tuyến đường:
pathping 203.0.113.10
tracert 203.0.113.10Đọc kết quả mtr mà không hoảng
Lỗi hay gặp nhất là lo lắng khi thấy mất gói ở một hop giữa đường. Router xử lý các gói gửi tới chính nó với mức ưu tiên thấp và thường giới hạn tốc độ trả lời ICMP. Hãy áp dụng các quy tắc sau:
- Mất gói ở một hop giữa nhưng không kéo dài sang các hop sau là do router đó giới hạn ICMP. Bỏ qua.
- Mất gói bắt đầu ở một hop và kéo dài tới mọi hop phía sau, kể cả hop cuối, mới là mất gói thật trên tuyến.
- Độ trễ tăng vọt ở một hop rồi giữ nguyên mức cao cho biết đoạn đường dài nằm ở đâu, thường là tuyến cáp biển hoặc điểm trao đổi lưu lượng ở nước khác.
- Độ trễ tăng vọt ở một hop rồi giảm lại ở các hop sau chỉ là router đó trả lời ICMP chậm.
- Dòng cuối cùng quan trọng nhất, vì đó chính là máy chủ của bạn.
Số AS từ tùy chọn -z cho biết lưu lượng đi qua những nhà mạng nào. Nếu kết nối tới một thành phố gần lại vòng ra nước ngoài rồi mới quay về, đó là lời giải cho con số cao bất thường. Người dùng mạng Viettel, VNPT hay FPT có thể thấy tuyến đi khác nhau tới cùng một máy chủ, nên hãy thử trên nhiều nhà mạng nếu có thể.
Đo một yêu cầu thật bằng curl
Ping chỉ đo mạng, còn người dùng phải chờ cả một yêu cầu hoàn chỉnh. curl có thể tách yêu cầu thành từng giai đoạn. Hãy chạy với web server trên máy thử, hoặc một website HTTPS bạn đặt ở đó:
curl -o /dev/null -s -w 'dns: %{time_namelookup}\nconnect: %{time_connect}\ntls: %{time_appconnect}\nttfb: %{time_starttransfer}\ntotal: %{time_total}\n' https://example.com/Trên Windows, gọi curl.exe (không phải alias của PowerShell) và ghi đầu ra vào NUL:
curl.exe -o NUL -s -w "connect: %{time_connect}\nttfb: %{time_starttransfer}\ntotal: %{time_total}\n" https://example.com/Các mốc thời gian tính bằng giây từ lúc bắt đầu yêu cầu. Hiệu số giữa connect và dns là một lượt khứ hồi TCP. TLS thường thêm một lượt khứ hồi với TLS 1.3, hoặc hai lượt với phiên bản cũ hơn. ttfb trừ tls là thời gian xử lý của máy chủ cộng thêm một lượt khứ hồi nữa. Đây là lý do khoảng cách gây hại nhiều như vậy: một yêu cầu HTTPS đã phải trả ba lượt khứ hồi trở lên trước khi byte đầu tiên về tới nơi.
Tùy chọn: đo băng thông bằng iperf3
Độ trễ và băng thông là hai chuyện khác nhau. Nếu bạn thường xuyên truyền file lớn, hãy đo băng thông giữa máy bạn và máy chủ bằng iperf3. Trên máy chủ:
sudo apt install iperf3
iperf3 -sMở cổng TCP 5201 trên firewall của máy chủ trong lúc thử, rồi chạy từ máy bạn:
iperf3 -c 203.0.113.10 -t 20
iperf3 -c 203.0.113.10 -t 20 -RTùy chọn -R đảo chiều để bạn đo cả chiều tải xuống lẫn tải lên. Đo xong hãy dừng tiến trình trên máy chủ và đóng cổng lại.
Cách so sánh công bằng
Một lần đo đơn lẻ rất dễ gây hiểu nhầm. Để so sánh các vị trí cho công bằng:
- Chạy cùng một bộ lệnh tới mọi vị trí ứng viên, từ cùng một máy, liên tiếp nhau.
- Lặp lại vào buổi sáng, buổi chiều và giờ cao điểm buổi tối.
- Đo từ nơi người dùng đang ở: điện thoại dùng 4G hoặc 5G, bạn bè ở quốc gia mục tiêu, hoặc một máy chủ sẵn có ở đó.
- Đo cả chiều ngược lại. Chạy
mtrtừ VPS tới IP public của người dùng, vì tuyến đi và tuyến về thường không giống nhau. - Ghi trung vị, độ dao động và tỷ lệ mất gói ở đích vào một bảng nhỏ rồi mới quyết định.
Khi kết quả sát nhau, các yếu tố khác sẽ quyết định: băng thông đi kèm, giá trên trang bảng giá và cấu hình bạn cần. Xóa các máy thử không dùng nữa, rồi làm theo checklist bảo mật VPS trong giờ đầu tiên trên máy bạn giữ lại.
Câu hỏi thường gặp
Ping tới VPS bao nhiêu là tốt?
Tùy khoảng cách. Hãy so với giới hạn vật lý khoảng 1 ms khứ hồi cho mỗi 100 km cáp quang và so giữa các vị trí ứng viên với nhau, thay vì đặt một con số cố định.
Vì sao mtr báo mất 100% gói ở một hop mà máy chủ vẫn phản hồi bình thường?
Router đó không trả lời hoặc giới hạn các gói thăm dò gửi tới chính nó. Nếu các hop sau và đích không mất gói, tuyến đường vẫn ổn.
Vì sao ping ổn mà website vẫn chậm?
Mỗi yêu cầu HTTPS cần nhiều lượt khứ hồi, cộng thêm thời gian xử lý của máy chủ. Hãy dùng bảng thời gian của curl để xem giai đoạn nào chậm.
Nên đo từ máy mình hay từ khu vực của người dùng?
Cả hai, nhưng khu vực của người dùng quan trọng hơn. Tuyến từ văn phòng bạn có thể khác hẳn tuyến mà nhà mạng của khách hàng sử dụng.
Đo trước, quyết định sau
Hãy triển khai vài máy nhỏ tính theo giờ ở các vị trí ứng viên từ console Cloudj, chạy các bài đo này trong một ngày và giữ lại vị trí phục vụ người dùng tốt nhất. Bạn có thể xem toàn bộ khu vực trên trang máy chủ cloud trước khi bắt đầu.