Mình hay nhận ticket lúc 2 giờ sáng: SSH vào được vài phút rồi rớt, RDP giật, ping thì thấp nhưng session cứ đứt. Đó không phải “VPS yếu” theo nghĩa thiếu RAM. Phần lớn case Giải cứu khi VPS cũ bị giật/đứt kết nối nằm ở jitter, packet loss, conntrack timeout hoặc node oversell. Bài này là checklist 5 bước mình dùng trong khoảng 20 phút để phân loại, rồi quyết định vá tạm hay chuyển Cloud VPS HCI như Dyvi.Cloud.

Giải cứu khi VPS cũ bị giật/đứt kết nối – Checklist vận hành trước khi đổi hạ tầng

Khách hay mô tả cùng một câu: “Máy vẫn chạy, vào web được lúc được lúc không, SSH ngồi một lúc là mất.” Panel vẫn hiện online. CPU/RAM trong biểu đồ nhà cung cấp trông bình thường. Đó đúng kiểu case Giải cứu khi VPS cũ bị giật/đứt kết nối — khác bài lag vì thiếu IOPS hay query chậm. Ở đây kết nối mới là thứ chết, không phải app “nặng”.

Mình tách rõ hai việc: vá cho session sống sót đêm nay, và chẩn đoán xem gốc rễ còn cứu được trên VPS cũ hay phải đổi hạ tầng. Giải cứu khi VPS cũ bị giật/đứt kết nối không phải tối ưu PHP. Nếu triệu chứng nghiêng CPU/iowait, đọc tại sao VPS cấu hình cao nhưng bị lag thường xuyên. SSH/RDP rớt, ping nhảy số — ở lại bài này.

Giải cứu khi VPS cũ bị giật/đứt kết nối là gì?

Câu trả lời ngắn gọn là: đây là quy trình phân loại và xử lý khi VPS đã chạy lâu bắt đầu giật hình, rớt SSH/RDP hoặc mất gói theo từng đợt — không phải cài lại OS cho có. Mục tiêu là giữ session sống trong vài giờ, đo được jitter/loss, rồi quyết định ở lại hay chuyển cụm HCI.

Giải cứu khi VPS cũ bị giật/đứt kết nối khác “sự cố hạ tầng mức độ thấp” ở chỗ nó lặp. Sự cố nhẹ tự hết sau 10 phút thì làm theo checklist ở hướng dẫn xử lý sự cố hạ tầng VPS. Còn giật/đứt mỗi tối, mỗi lần live-migrate phía hypervisor, hoặc mỗi khi hàng xóm trên cùng node đẩy traffic — đó là bệnh mãn tính của máy cũ trên node đơn, không phải spike ngẫu nhiên.

Ba triệu chứng mình gộp chung vì khách mô tả lẫn: giật là jitter — ping trung bình 8ms nhưng lệch 40–80ms, RDP/stream khựng từng nhịp; đứt kết nối là TCP reset, SSH freeze rồi “broken pipe”, tool báo connection reset. Ping ICMP nhỏ vẫn xanh không chứng minh TCP 443/22 ổn. Nhiều VPS cũ pass ping 32 byte rồi fail ngay gói lớn hơn vì MTU hoặc shaping.

VPS “cũ” ở đây không nhất thiết là máy 5 năm. Là máy trên hypervisor đời trước: OpenVZ, node KVM oversell, NIC 1Gb chia cho vài chục VM, không có failover khi switch/uplink rung. Giải cứu khi VPS cũ bị giật/đứt kết nối đôi khi chỉ cần keepalive và chỉnh MTU. Nhiều khi phải thừa nhận: TCP stack trong VM khỏe, đường vật lý phía dưới mới là chỗ đứt.

Vì sao VPS cũ hay giật và đứt kết nối dù ping vẫn thấp?

Thực tế là ping trung bình thấp chỉ nói latency lúc gói đi được, không nói gói có đi đều không. Với Giải cứu khi VPS cũ bị giật/đứt kết nối, mình hay bắt 5 nhóm nguyên nhân — gần như luôn đủ cho case production:

• Packet loss và jitter trên uplink/node: NIC node chia sẻ, hàng xóm backup/scrape, switch rẻ. Jitter trên 30–50ms hoặc mất gói trên 1% là đủ để SSH/RDP trông như “đứt” dù CPU rảnh.
• Conntrack đầy hoặc idle timeout: NAT/CGNAT phía ISP hoặc firewall VPS cắt session idle. SSH im 2–5 phút là rớt; ping vẫn sống vì ICMP không nằm cùng state TCP.
• MTU/PMTUD blackhole: Ping 56 byte OK, SCP/HTTPS treo. Thường gặp khi VPS hoặc nhà mạng dùng PPPoE/VLAN mà VM để MTU 1500.
• Steal time kéo TCP không kịp ACK: Node oversell, %st cao, kernel không xử lý socket đúng nhịp. Nhìn như mạng kém, gốc là CPU bị hypervisor lấy.
• Live-migrate / NIC reset phía hypervisor: dmesg có virtio_net, xennet, “link down”. Máy cũ hay bị nhà cung cấp dời VM im lặng — RDP đứt đúng lúc đó.

Chín trên mười ticket Giải cứu khi VPS cũ bị giật/đứt kết nối rơi vào một trong năm nhóm trên, không phải “cài lại nginx là xong”. App timeout chỉ là hệ quả: PHP-FPM, reverse proxy hay bot ads thấy connection reset rồi retry chồng retry. Nhóm ads/tool/MMO còn đau hơn vì session dài — xem thêm chạy ads, tool, MMO nên chọn VPS thế nào để không bị đứng máy.

5 dấu hiệu phân biệt giật mạng với lag CPU/I/O

Trước khi reboot cho đỡ bực, mình nhìn 5 tín hiệu này. Có từ 2 tín hiệu mạng trở lên thì đừng lãng phí thời gian tối ưu PHP:

• Ping trung bình thấp nhưng mdev/stddev cao: ping -c 100 IP ra 8ms mà độ lệch 40ms+ là jitter, không phải “mạng nhanh”.
• Loss trong mtr nằm hop trong AS nhà cung cấp: Loss ở máy bạn hoặc hop ISP đầu là đường nhà. Loss ổn định từ hop datacenter trở đi là VPS/node.
• SSH freeze, gõ không ra chữ, vài chục giây sau broken pipe: Điển hình TCP stall. CPU 100% thường vẫn gõ được, chỉ chậm — khác hẳn đóng băng.
• ICMP sống, TCP 22/3389/443 chết từng đợt: Shaping, conntrack hoặc flood. Ping xanh không kết luận được.
• Đứt theo giờ cao điểm hoặc sau 20–40 phút idle: Giờ cao điểm = noisy neighbor/oversell. Idle = keepalive/NAT timeout. Hai pattern khác nhau, đừng chữa một kiểu.

%wa và %st vẫn nên xem — nếu steal time > 5% kèm giật, mình xử như hạ tầng chứ không như Wi-Fi. Phần đọc top/iostat chi tiết nằm ở VPS cấu hình cao vẫn lag. Giải cứu khi VPS cũ bị giật/đứt kết nối chỉ khác ở chỗ: ưu tiên mtr, ss -ti, dmesg trước khi đụng slow query.

Quy trình Giải cứu khi VPS cũ bị giật/đứt kết nối gồm mấy bước?

Mình chạy 5 bước, khoảng 20–40 phút. Làm đủ thì biết đêm nay vá được hay phải dựng máy mới:

1. Tách “máy bạn” khỏi “máy VPS”: Ping từ 4G và từ một DC khác. Chỉ Wi-Fi giật thì đừng đổ cho VPS. Cả hai đường loss → nghi node. SSH đứt mà Console KVM vào được thì vào console ngay, đừng reconnect 20 lần.
2. Đo jitter và loss đúng cách: ping -c 100 lấy mdev. mtr -rwzbc 100 IP. Loss > 1% hoặc jitter > 50ms trong DC là đủ. Gói lớn: ping -s 1472 -M do — fail trong khi ping nhỏ OK thì hạ MTU (1450–1480).
3. Giữ session sống sót (vá tạm): Client SSH: ServerAliveInterval 30, ServerAliveCountMax 4 trong ssh_config. Server: ClientAliveInterval 30. Chạy việc dài trong tmux/screen. RDP thì tắt compositor. Đây là băng gạc — hết giật nền thì bỏ được; không hết thì chỉ mua thêm giờ chẩn đoán.
4. Loại trừ conntrack, MTU, NIC reset: dmesg -T | tail -n 80 tìm link down, virtio, xennet. sysctl net.netfilter.nf_conntrack_count sát max thì tăng max hoặc giảm timeout, tìm process mở quá nhiều connection. ss -ti xem retrans. Restart networking/NetworkManager trước khi reboot cả máy — reboot “ổn 30 phút rồi đứt lại” gần như chắc chắn không phải bug app.
5. Chốt vá tiếp hay chuyển hạ tầng: Loss/jitter trong AS nhà cung cấp, %st cao, dmesg NIC reset lặp, đứt đúng giờ cao điểm — ngừng nâng gói trên cùng node. Dựng Cloud VPS HCI, rsync/snapshot, cắt DNS. Ticket vendor cũ kèm output mtr nếu còn trong SLA; đừng chờ họ “reset port” lần thứ tư.

Năm bước trên là toàn bộ Giải cứu khi VPS cũ bị giật/đứt kết nối ở lớp kỹ thuật. Bỏ bước 1 sẽ chữa nhầm Wi-Fi. Bỏ bước 4 sẽ reboot suốt tháng. Bỏ bước 5 sẽ trả tiền VPS cũ thêm một năm rồi vẫn rớt SSH.

Cloud VPS Dyvi.Cloud giải cứu kết nối thế nào?

Khi bước 5 ra kết luận “node cũ”, mình không khuyên mua thêm vCPU trên cùng hypervisor. Giải cứu khi VPS cũ bị giật/đứt kết nối lúc này cần đường mạng và failover khác. Dyvi.Cloud xử đúng nhóm nguyên nhân kết nối, không phải slogan “mạng nhanh”:

• HCI thay node đơn: Live-migrate/im lặng trên máy cũ hay kéo theo NIC reset. Cụm HCI dự phòng: node hoặc link sự cố thì workload nhảy, không để TCP treo phút rồi đứt.
• Băng thông chuẩn hóa: 20Gb nội bộ datacenter, 10Gb cổng Internet, uplink 40Gb, lưu lượng không giới hạn. Jitter từ NIC 1Gb chia 40 VM hết đất sống trên fabric này.
• DC TIA-942 Tier 3 trong nước: Viettel IDC HHT, VNPT Đà Nẵng, FPT Hà Nội, FPT HCM, ODS HCM. User Việt không phải hop quốc tế chỉ để SSH vào máy đặt SG/US.
• Anti-DDoS lớp ngoài: Nhiều case “đứt kết nối” thực ra là SYN/UDP flood lấp conntrack. Lọc trước khi vào VPS thì SSH không chết theo bảng state.
• Kích hoạt khoảng 5 phút, snapshot, resize giữ IP: Dựng máy cứu hộ nhanh, copy data, cắt over. Không bị kẹt mô hình “tạo VPS mới rồi mất IP, DNS treo 24 giờ”. Support 24/7/365 khi migrate đêm.

Tóm lại, Giải cứu khi VPS cũ bị giật/đứt kết nối trên Dyvi.Cloud là đổi lớp mạng và hypervisor, không phải cài lại cùng một node. Chi tiết stack nằm ở giới thiệu Dyvi.Cloud. Cần cân ngân sách thì đối chiếu VPS giá rẻ để khỏi mua nhầm gói oversell “rẻ mà giật”.

Khi nào nên bỏ VPS cũ, không vá tiếp?

Không phải mọi session rớt đều phải migrate. Keepalive + MTU xong ổn 1–2 tuần thì ở lại. Mình chuyển khi có 2–3 mục dưới đây:

• mtr loss lặp trong AS nhà cung cấp, ticket “reset port” không hết sau 48 giờ.
• Đứt đúng khung 19:00–23:00 dù traffic app không tăng — noisy neighbor.
• Reboot/panel rescue xong khỏe 20–40 phút rồi pattern cũ trở lại.
• dmesg NIC reset / virtio error lặp, nhà cung cấp không đổi node.
• Steal time > 5% kéo dài kèm TCP retrans — oversell, nâng gói trên chỗ đó vô nghĩa.
• Production (ads, tool, web thanh toán) không chịu nổi RDP/SSH rớt giữa ca.

Gặp các mốc trên mà vẫn ở lại là chấp nhận giật như một tính năng. Giải cứu khi VPS cũ bị giật/đứt kết nối lúc này là cắt, không phải tối ưu thêm plugin. Cấp độ tự quản hay nhờ managed xem các cấp độ quản lý VPS — migrate hạ tầng và migrate trách nhiệm ops là hai việc khác nhau.

Câu hỏi thường gặp về Giải cứu khi VPS cũ bị giật/đứt kết nối

VPS giật nhưng ping vài ms thì có phải mạng ổn không?

Không. Ping trung bình thấp không loại trừ jitter và loss. Nhìn mdev và cột loss/jitter trong mtr, đừng nhìn mỗi số 8ms. Giải cứu khi VPS cũ bị giật/đứt kết nối bắt đầu từ hai con số đó, không từ cảm giác “ping được là khỏe”.

SSH cứ idle 5–10 phút lại rớt, có phải VPS hỏng?

Thường là idle timeout trên NAT/firewall, không phải disk hỏng. Bật ServerAliveInterval 30 hai phía. Hết rớt thì xong. Vẫn rớt khi đang gõ liên tục thì chuyển sang đo mtr — lúc đó mới là đứt đường thật.

Reboot xong ổn nửa tiếng rồi đứt lại thì làm gì?

Đừng reboot thêm lần nữa. Pattern này là hypervisor phân bổ lại rồi noisy neighbor quay lại — đúng bệnh cần Giải cứu khi VPS cũ bị giật/đứt kết nối bằng đổi cụm, không bằng reset. Ghi mtr và %st đúng lúc đứt; song song dựng máy HCI. Reboot chỉ mua thời gian.

Có Giải cứu khi VPS cũ bị giật/đứt kết nối mà không đổi nhà cung cấp không?

Có, nếu gốc là keepalive, MTU hoặc conntrack trên chính VM. Không, nếu loss nằm hop datacenter hoặc NIC reset phía host. Vá được lớp OS thì vá; hết đất OS thì đổi cụm — đó vẫn là Giải cứu khi VPS cũ bị giật/đứt kết nối, chỉ khác chỗ cắt.

Chuyển sang Dyvi.Cloud có mất dữ liệu hoặc IP không?

Dựng VPS mới khoảng 5 phút, copy bằng rsync/snapshot, trỏ DNS. Resize sau này trên Dyvi.Cloud giữ IP, OS và disk. IP public cũ của vendor kia thường không mang sang được — chốt TTL DNS thấp trước khi cắt. Anti-DDoS và DC trong nước giảm đúng nhóm đứt kết nối mà VPS cũ hay dính.

Bắt đầu Giải cứu khi VPS cũ bị giật/đứt kết nối với Dyvi.Cloud

Session rớt không chờ bạn nâng RAM. Đo jitter/loss, vào console, vá keepalive/MTU/conntrack trong đêm, rồi nhìn thẳng vào mtr và %st. Nếu gốc ở node cũ thì ngừng trả tiền cho đường mạng chập chờn. Giải cứu khi VPS cũ bị giật/đứt kết nối lúc đó là chuyển Cloud VPS HCI — kích hoạt khoảng 5 phút, snapshot, support 24/7 — chứ không phải reboot thêm tuần nữa.

Xem hạ tầng tại giới thiệu Dyvi.Cloud hoặc dyvi.cloud. Đối chiếu lag CPU/I/O ở VPS cấu hình cao nhưng bị lag thường xuyên và sự cố nhẹ ở hướng dẫn xử lý sự cố hạ tầng. Tổng quan dịch vụ tại trang chủ.