Khắc phục sự cố mất kết nối từ xa cho Claude Code: Triệu chứng, tiêu chí nhận biết và giải pháp của sáu kiểu ngắt kết nối

Chạy Claude Code từ xa, điều khó chịu nhất không phải là không kết nối được, mà là kết nối được rồi lại bị ngắt, và mỗi lần ngắt nguyên nhân lại khác nhau.

Từ "mất kết nối" thực ra bao trùm sáu loại lỗi hoàn toàn khác nhau. Hiện tượng của chúng mỗi loại một đặc trưng riêng, cách sửa cũng chẳng liên quan gì đến nhau — coi sự cố mất kết nối dài do chuyển mạng là do máy ngủ, thì tắt chế độ ngủ cũng vô ích; coi kết nối nửa chết là do mạng kém mà ngồi chờ, thì chờ đến sáng nó cũng không tự khỏi.

Bài viết này suy ngược nguyên nhân theo hiện tượng bạn thực sự nhìn thấy: với mỗi kiểu ngắt kết nối, đưa ra triệu chứng, cách xác nhận đúng là nó, và giải pháp tương ứng. Muốn bắt tay vào làm luôn, hãy nhảy đến danh sách kiểm tra ở phần cuối.

Bài này chỉ nói về khắc phục sự cố mất kết nối. Cách thiết lập truy cập từ xa xem "Truy cập từ xa Claude Code: Tắt máy cục bộ vẫn điều khiển phiên từ mọi nơi", cách dùng trên điện thoại xem "Kết nối Claude Code từ điện thoại: Xem phiên và phê duyệt công cụ trên iOS mọi lúc".

Đối chiếu triệu chứng trước: bạn đang thấy loại nào

Kết nối từ xa gồm hai phía: máy phát triển chạy Claude Code ←→ thiết bị xem trên tay bạn. Một trong hai phía gặp sự cố đều thể hiện là "bị ngắt", nhưng hiện tượng có khác biệt:

Hiện tượng bạn thấy	Rất có khả năng là	Nhảy đến
Phiên đột nhiên đứng yên, kết nối lại thấy tiến độ cũng dừng ở đúng thời điểm đó	Máy phát triển ngủ / khóa màn hình	§1
Ngắt đúng lúc bước vào thang máy, chuyển 4G, đổi WiFi	Kết nối dài bị cắt	§2
Tắt terminal máy cục bộ, hoặc máy cục bộ ngủ, phía từ xa lập tức ngắt theo	Ràng buộc cứng của giải pháp chiếu màn hình	§3
Hiển thị trực tuyến, nhưng gửi tin nhắn chìm nghỉm, không có bất kỳ lỗi nào	Kết nối nửa chết	§4
Kết nối lại được, nhưng kết nối về là phiên trống / tin nhắn trong thời gian mất kết nối không còn nữa	Kết nối lại không gắn về phiên gốc	§5
Cách vài giờ kết nối lại, phiên biến mất	Tiến trình bị thu hồi, và không có khôi phục nguội	§6

Dễ chẩn đoán sai nhất là loại thứ tư: nó không báo lỗi. Trạng thái kết nối vẫn xanh, tin nhắn gửi được, chỉ là không bao giờ có hồi đáp — khó tra hơn cả khi ngắt hẳn, vì mọi đèn báo đều nói với bạn "mọi thứ bình thường".

1. Máy phát triển ngủ / khóa màn hình / gập nắp

Triệu chứng: Phiên đứng yên hoàn toàn tại một thời điểm nào đó. Kết nối lại, tiến độ vẫn dừng ở thời điểm ngắt, không tiến thêm một bước nào.

Tại sao: Nhiều người nghĩ "máy phát triển của tôi lúc nào cũng bật", nhưng hệ thống ngủ đông, ngủ khi gập nắp, khóa màn hình theo giờ đều có thể tạm dừng hoặc giết trực tiếp tiến trình Claude Code. Phía thiết bị xem thấy được chính là "đột nhiên đứng yên".

Cách xác nhận: Quay lại máy phát triển xem tiến trình đó còn không, trong nhật ký hệ thống có ghi nhận ngủ không. Nếu tiến trình vẫn còn nhưng dấu thời gian dừng ở thời điểm mất kết nối, thì gần như chính là nó.

Giải pháp: Đặt power plan của máy phát triển thành "không ngủ / gập nắp không ngủ". Đây là cách duy nhất chữa tận gốc — bất kỳ giải pháp từ xa nào cũng không cứu được một cỗ máy đã ngủ say.

2. Chuyển mạng khiến kết nối dài bị cắt

Triệu chứng: Ngắt tại một khoảnh khắc rất rõ ràng — bước vào thang máy, WiFi chuyển 4G, băng rộng nhà nửa đêm quay số lại.

Tại sao: Đồng bộ thời gian thực từ xa dựa vào một kết nối dài (WebSocket / SSH). IP vừa đổi, kết nối này lập tức mất hiệu lực, không có bất kỳ thương lượng nào.

Cách xác nhận: Thời điểm mất kết nối trùng khớp với thời điểm bạn chuyển mạng, chính là nó.

Giải pháp: Loại này không thể tránh khỏi, chỉ có thể dựa vào tự động kết nối lại + backoff để khắc phục (1s→2s→5s…, tránh vừa ngắt là dồn dập kết nối lại). SSH trần không có khả năng này, ngắt là ngắt, phải gõ tay. Khi chọn giải pháp, đây là tiêu chí cứng.

3. Giải pháp chiếu màn hình: máy cục bộ phải mở ở nền trước

Triệu chứng: Terminal máy cục bộ vừa đóng, hoặc máy cục bộ vừa ngủ, phía điện thoại lập tức ngắt theo. Không phải từ từ timeout, mà là đồng bộ mất hiệu lực.

Tại sao: Remote Control chính thức của Anthropic là chiếu phiên đang chạy trên máy cục bộ của bạn lên điện thoại/trình duyệt. Tiền đề của nó là Claude Code trên máy cục bộ luôn chạy ở nền trước, máy cục bộ luôn trực tuyến. Máy cục bộ vừa rơi khỏi mạng, phía từ xa không có vòng đời độc lập nào để bám vào.

Cách xác nhận: Đóng cửa sổ terminal trên máy cục bộ, xem phía từ xa có ngắt trong cùng một giây không. Nếu có, bạn đang dùng giải pháp chiếu màn hình.

Giải pháp: Chuyển sang kiến trúc dịch vụ daemon thường trực phía máy phát triển — phía chạy phiên được làm thành dịch vụ nền tự khởi động khi bật máy, sống độc lập với thiết bị xem của bạn. Thiết bị xem có tắt, có đổi, có ngắt, nó vẫn chạy bình thường trên máy phát triển. Đây là khác biệt bản chất giữa "chiếu màn hình" và "dịch vụ thường trực", không phải thứ chỉnh tham số là ra được.

4. Kết nối nửa chết (half-open): loại khó phát hiện nhất

Triệu chứng: Hiển thị trực tuyến, gửi tin nhắn không phản hồi, cũng không báo lỗi. Có thể kẹt vài phút, cũng có thể kẹt mãi đến khi bạn kết nối lại thủ công.

Tại sao: Khi mạng bị gián đoạn âm thầm (mục bảng NAT hết hạn, thiết bị trung gian mất trạng thái, tín hiệu yếu đến mức chỉ mất gói mà không đứt liên kết), hai đầu TCP có thể đều tưởng mình vẫn đang kết nối, còn dữ liệu thì không bao giờ qua được nữa. Không có heartbeat, cả hai bên sẽ duy trì ảo giác này mãi.

Cách xác nhận: Trạng thái kết nối hiển thị bình thường, nhưng tin nhắn gửi ra không có xác nhận đã đến mà cũng không báo lỗi; sau khi ngắt thủ công rồi kết nối lại thì lập tức phục hồi — chính là nó.

Giải pháp: Trên kết nối phải chạy heartbeat (keepalive ping): trong thời gian quy định không nhận được bất kỳ phản hồi nào từ phía bên kia, thì phán định đây là kết nối nửa chết, chủ động ngắt và kết nối lại, chứ không ngồi chờ. Tiêu chí phải là "không nhận được phản hồi", không thể là "không có báo lỗi" — kết nối nửa chết không bao giờ báo lỗi.

5. Kết nối lại không gắn về phiên gốc / mất tin nhắn

Triệu chứng: Ngắt rồi kết nối lại được, nhưng kết nối về hoặc là phiên trống, hoặc toàn bộ tin nhắn đối phương gửi trong thời gian mất kết nối đều không còn.

Tại sao: Kết nối lại chỉ là tạo mới một kết nối, không đăng ký kết nối này vào phiên gốc; tin nhắn trong thời gian mất kết nối cũng không được lưu vào bộ đệm cho bạn.

Cách xác nhận: Sau khi kết nối lại, ID phiên đã đổi, hoặc lịch sử chỉ bắt đầu từ thời điểm kết nối lại.

Giải pháp: Chọn giải pháp có khả năng sau khi kết nối lại tự động đăng ký vào phiên gốc, và phát lại lịch sử trong thời gian mất kết nối. Chỉ kết nối lại được mà không gắn về được, thì coi như kết nối vô ích.

6. Tiến trình phiên bị thu hồi, và không có khôi phục nguội

Triệu chứng: Mất kết nối trong thời gian ngắn rồi kết nối lại đều bình thường, nhưng cách vài giờ quay lại, phiên đã biến mất.

Tại sao: Tiến trình phiên rảnh trong thời gian dài có thể bị thu hồi, bản thân daemon cũng có thể đã khởi động lại (nâng cấp, sập rồi được kéo lên). Trạng thái phiên trong bộ nhớ theo đó biến mất.

Cách xác nhận: Chỉ tái hiện khi mất kết nối lâu, ngắt ngắn thì không tái hiện.

Giải pháp: Cần khả năng khôi phục nguội — trạng thái phiên được ghi xuống đĩa, tiến trình không còn cũng có thể khôi phục ngữ cảnh từ đĩa. Trường hợp lý tưởng là bạn gửi một tin nhắn là nó tự động khôi phục và tiếp tục, bạn không hề hay biết.

Danh sách kiểm tra (áp dụng được cho mọi giải pháp)

Làm theo thứ tự, mỗi bước đều có thể độc lập loại trừ một nguyên nhân:

1. Máy chạy phiên có bị ngủ / khóa màn hình không? → Tắt ngủ tự động, gập nắp không ngủ. (§1)
2. Thời điểm mất kết nối có trùng với thời điểm bạn chuyển mạng không? → Cần giải pháp có tự động kết nối lại + backoff, đừng dựa vào SSH trần. (§2)
3. Đóng terminal máy cục bộ, phía từ xa có lập tức ngắt không? → Ràng buộc cứng của giải pháp chiếu màn hình, phải đổi sang kiến trúc daemon thường trực. (§3)
4. Kẹt ở "hiển thị trực tuyến nhưng gửi tin nhắn không phản hồi"? → Kết nối nửa chết, chỉ có phát hiện heartbeat mới tự cứu được. (§4)
5. Sau khi kết nối lại phiên trống / tin nhắn ít đi? → Cần "gắn về phiên gốc + phát lại lịch sử". (§5)
6. Chỉ khi ngắt lâu phiên mới bị mất? → Cần ghi xuống đĩa + khôi phục nguội. (§6)

Đi vào giải pháp cụ thể

Trong sáu mục trên, chỉ có mục 1 là vấn đề cài đặt máy của bạn, năm mục còn lại đều do kiến trúc quyết định — đã định đoạt ngay từ khi chọn giải pháp, sau khi xảy ra sự cố có chỉnh tham số cũng không cứu lại được.

Một giải pháp từ xa không ngắt kết nối cần đồng thời có: daemon thường trực phía máy phát triển (tương ứng với rủi ro còn lại của §1 và §3), tự động kết nối lại + backoff (§2), phát hiện heartbeat (§4), kết nối lại gắn về phiên gốc + phát lại lịch sử (§5), ghi xuống đĩa và khôi phục nguội (§6).

Bộ PandaNpc + pandapaw được xây dựng bám sát từng mục trong sáu điều này: pandapaw được đăng ký trên máy phát triển thành daemon thường trực tự khởi động khi bật máy (không phải cửa sổ terminal bạn phải tự mở, sập sẽ được tự động kéo lên); phía thiết bị xem mất kết nối sẽ tự kết nối lại kèm backoff; trên kết nối chạy heartbeat, không nhận được phản hồi thì phán định nửa chết và chủ động kết nối lại; sau khi kết nối lại tự động đăng ký vào phiên gốc và phát lại lịch sử trong thời gian mất kết nối; tiến trình phiên dù có bị thu hồi, chỉ cần gửi một tin nhắn là có thể khôi phục nguội từ đĩa và tiếp tục.

Cách cài đặt và kết nối cụ thể, xem "Truy cập từ xa Claude Code"; cách xem phiên và phê duyệt công cụ trên điện thoại, xem "Kết nối Claude Code từ điện thoại".

Một cái bẫy đi kèm: chạy từ xa đừng vướng vào tính phí

Khi khắc phục sự cố mất kết nối, người ta dễ tiện tay đổi sang chạy claude -p (chế độ headless), nhưng kể từ ngày 15 tháng 6 năm 2026, Anthropic đã điều chỉnh cách tính phí — headless không còn dùng hạn mức đăng ký nữa, mà tiêu vào một khoản credit SDK nhỏ theo tháng, dùng hết thì tính phí theo API, dùng nhiều rất dễ vượt ngân sách. Chế độ tương tác (claude REPL) vẫn dùng hạn mức đăng ký. Khi đổi giải pháp để khắc phục mất kết nối, chú ý đừng tiện tay đổi luôn cả chế độ tính phí.