MacBook có thể bắt đầu hụt khả năng tạo kết nối mạng mới sau đúng 49 ngày 17 giờ 2 phút 47 giây uptime liên tục, do bộ đếm tcp_now 32-bit trong macOS chạm ngưỡng 4.294.967.295 mili giây rồi quay về 0. Lỗi này khiến MacBook không còn mở được kết nối TCP mới một cách ổn định dù máy chưa hề tắt. Bug này đánh vào stack TCP/IP nên máy vẫn có thể ping được nhưng dịch vụ nền lại không mở thêm kết nối mới. Nhóm cần chú ý nhất là quản trị viên và doanh nghiệp đang dùng MacBook hoặc Mac mini như máy build, máy test hay proxy, vì chỉ một MacBook treo kết nối cũng đủ làm đứt chuỗi automation. Vấn đề lớn nằm ở chỗ lỗi khó chẩn đoán, nên rất dễ làm đội vận hành tìm sai nguyên nhân.
Điều gì vừa xảy ra và dữ liệu nào xác thực?
Dữ kiện quan trọng nhất đều quy về mốc 2^32 mili giây, tương đương 49,7 ngày. Một nhóm kỹ sư vận hành hệ thống iMessage cho biết nhiều MacBook và máy Mac khác mất khả năng mở kết nối TCP mới khi uptime chạm ngưỡng này, trong khi kết nối cũ vẫn còn sống và máy vẫn trả lời ping. Đây là kiểu lỗi rất dễ làm đội IT hiểu nhầm sang firewall, DNS hoặc phần mềm giám sát, vì bề ngoài máy vẫn có vẻ đang hoạt động bình thường. Báo cáo ban đầu mô tả đây không phải hiện tượng chậm máy chung chung, mà là một bug rollover khá cụ thể trong lớp TCP/IP. Điểm đáng ngại là lỗi chỉ lộ ra khi máy đủ lâu không reboot, nên nhiều hệ thống văn phòng sẽ không phát hiện sớm.
Phần cơ chế cũng đủ rõ để đối chiếu chéo. macOS dùng biến tcp_now để đếm mili giây kể từ lúc khởi động, nhưng biến này chỉ là số nguyên không dấu 32-bit nên sẽ quay vòng về 0 sau hơn 49 ngày. Khi chuyện đó xảy ra, khâu dọn dẹp kết nối TCP đã đóng có thể so sánh sai mốc thời gian, làm các kết nối TIME_WAIT không bị thu hồi đúng lúc và khiến việc mở kết nối mới thất bại. Trade-off ở đây là không phải mọi MacBook chạm mốc 49,7 ngày đều hỏng mạng ngay, vì mức ảnh hưởng còn phụ thuộc lượng kết nối mới mà MacBook đó tạo ra sau thời điểm rollover. Với các máy chuyên chạy automation hoặc đồng bộ liên tục, xác suất lộ lỗi thường cao hơn máy dùng cá nhân bật tắt mỗi ngày.
Tác động thực tế với người dùng hoặc doanh nghiệp là gì?
Với người dùng cá nhân, lỗi này có thể trôi qua khá âm thầm nếu MacBook vẫn được khởi động lại định kỳ sau cập nhật hệ thống, nên nhiều người sẽ chỉ nhận ra khi MacBook mất kết nối ở thời điểm khó chịu nhất. Nhưng với đội vận hành dùng MacBook hay Mac mini cho tác vụ 24/7, rủi ro lại rất thật: máy vẫn online, giám sát cơ bản vẫn báo tốt, nhưng webhook, API worker, phiên SSH mới hoặc tiến trình đồng bộ cloud lại bắt đầu thất bại. Một MacBook build CI cho ứng dụng iOS hoặc một proxy văn phòng nhỏ đều có thể gặp nghẽn đúng lúc cần ổn định nhất. Nhìn theo góc đó, bài toán ở đây là vận hành dịch vụ chứ không còn là chuyện một chiếc laptop bị chậm đi sau nhiều ngày uptime. Nếu hệ thống đang gánh tác vụ mạng dày, vài phút nghẽn kết nối cũng đủ làm hỏng cả chuỗi job phía sau.
Điều nên làm ngay là kiểm tra uptime của các máy Mac đang chạy tác vụ dài ngày và thêm lịch restart chủ động trước ngưỡng 49 ngày nếu môi trường chưa có bản vá, đặc biệt nếu MacBook đang giữ vai trò build hoặc proxy. Với người dùng phổ thông, reboot định kỳ vẫn là cách giảm rủi ro đơn giản nhất. Với doanh nghiệp, bug này là lời nhắc rằng một hệ macOS ổn định quan trọng không kém phần cứng mới, nhất là khi Apple Intelligence khiến nhiều người giữ máy Mac online lâu hơn để thử tính năng AI mới. Đây không phải lỗi giao diện nhỏ mà là cảnh báo vận hành cần xử lý sớm.
Ai đang theo dõi roadmap phần cứng Apple cũng có thể xem thêm bài MacBook Pro M5 để thấy vì sao nhóm người dùng Mac hiệu năng cao ngày càng có xu hướng duy trì máy chạy liên tục cho build, test và automation. Xu hướng này khiến những lỗi rollover kiểu cũ trở nên đáng ngại hơn, vì máy càng ít reboot thì cửa sổ va chạm với bug càng rõ. Với đội kỹ thuật, đây cũng là lý do nên gắn việc kiểm tra uptime vào checklist vận hành định kỳ. Chỉ cần phát hiện sớm trước mốc 49 ngày, phần lớn rủi ro có thể giảm bằng lịch restart chủ động.
Nguồn tham khảo: Notebookcheck.