Cách sửa lỗi 'Error: read ECONNRESET' trong Node.js - Khắc phục sự cố ngắt kết nối đột ngột

LỗiBạn có lẽ đang nhìn vào một log production đầy những dòng stack trace bí ẩn này:

Error: read ECONNRESET
    at TCP.onStreamRead (node:internal/stream_base_commons:217:20)
    at errnoException (node:internal/errors:523:12)

Về mặt kỹ thuật, ứng dụng Node.js của bạn đã cố gắng lấy dữ liệu từ một socket TCP, nhưng phía bên kia (remote peer) đã đột ngột ngắt kết nối. Thay vì thực hiện quy trình bắt tay bốn bước FIN tiêu chuẩn, phía bên kia đã gửi một gói tin RST (Reset). Socket đã chết, đường ống bị hỏng, và ứng dụng của bạn sẽ bị crash ngay lập tức nếu bạn không bắt (catch) lỗi này.

Tại sao lỗi này xảy ra trong môi trường ProductionTrong hầu hết các cụm production, ECONNRESET không phải là lỗi code. Đó là sự xung đột về thời gian (timing conflict) giữa ứng dụng và hạ tầng của bạn.

1. Xung đột Timeout Keep-AliveNode.js sử dụng Keep-Alive để tái sử dụng các kết nối và giảm độ trễ. Tuy nhiên, mọi thành phần hạ tầng—từ AWS ALB đến Nginx—đều có một khoảng thời gian chờ (idle timeout). Nếu AWS Load Balancer mặc định timeout là 60 giây nhưng máy chủ Node.js của bạn lại giữ trạng thái chờ trong 65 giây, bộ cân bằng tải sẽ ngắt kết nối trước. Khi ứng dụng của bạn cố gắng sử dụng socket "thây ma" (zombie) đó, bộ cân bằng tải sẽ phản hồi bằng một lệnh reset.

2. Cạn kiệt tài nguyên phía thượng nguồn (Upstream)Các máy chủ bị quá tải thường ngắt kết nối để duy trì hoạt động. Nếu một dịch vụ thượng nguồn đạt đến giới hạn max_connections hoặc bị crash ở cấp độ kernel, nó sẽ ngay lập tức gửi các gói tin RST đến tất cả các client đang hoạt động. Trong môi trường Kubernetes, điều này thường thấy khi một pod bị OOMKilled (Hết bộ nhớ).

3. Các thiết bị trung gian (Middleboxes) "tàng hình"Các firewall dạng stateful và Web Application Firewall (WAF) đôi khi xóa các mục kết nối "không hoạt động" khỏi bảng trạng thái của chúng mà không thông báo cho các điểm đầu cuối. Ứng dụng của bạn nghĩ rằng đường truyền vẫn thông suốt, nhưng gói tin tiếp theo nó gửi đi sẽ va phải một "bức tường" và kích hoạt lệnh reset.

Các bước khắc phục### Bước 1: Cấu hình đồng nhất các bộ đếm thời gian Keep-AliveKhi chạy Node.js sau một proxy như Nginx hoặc HAProxy, giá trị keepAliveTimeout của máy chủ phải lớn hơn timeout của proxy. Điều này đảm bảo rằng proxy là bên khởi xướng việc đóng kết nối một cách an toàn (graceful close), chứ không phải tiến trình Node.js.

const server = http.createServer(app);

// Đặt giá trị này cao hơn idle timeout của Load Balancer (ví dụ: 60s)
server.keepAliveTimeout = 65000; 
// headersTimeout phải cao hơn một chút so với keepAliveTimeout
server.headersTimeout = 66000;

Bước 2: Bảo vệ các Socket ListenerNếu bạn đang làm việc với các module net thuần túy hoặc các driver cơ sở dữ liệu cũ, một lỗi socket không được xử lý sẽ làm dừng tiến trình của bạn. Hãy luôn gắn một error listener ở cấp độ socket.

const client = net.connect({ port: 8080 }, () => {
  console.log('Kết nối thành công');
});

client.on('error', (err) => {
  if (err.code === 'ECONNRESET') {
    console.error('Máy chủ từ xa đã reset kết nối. Đang khởi tạo trì hoãn (backoff)...');
    return;
  }
  throw err;
});

Bước 3: Triển khai cơ chế thử lại (Retry Logic) mạnh mẽCác hệ thống phân tán luôn có thể gặp lỗi. Đối với các thao tác có tính idempotent (GET, PUT, DELETE), bạn không bao giờ nên để một lỗi ECONNRESET duy nhất làm hỏng yêu cầu của người dùng. Sử dụng axios-retry cho phép bạn xử lý những lỗi này một cách minh bạch.

import axios from 'axios';
import axiosRetry from 'axios-retry';

const http = axios.create();

axiosRetry(http, {
  retries: 3,
  retryCondition: (error) => {
    // Thử lại khi có lỗi mạng hoặc các mã reset cụ thể
    return axiosRetry.isNetworkError(error) || error.code === 'ECONNRESET';
  },
  retryDelay: axiosRetry.exponentialDelay // Bắt đầu nhỏ, tăng dần lên 1s, 2s, 4s...
});

Bước 4: Kiểm tra độ ổn định của phía thượng nguồn (Upstream)Theo dõi các dịch vụ thượng nguồn để phát hiện các trường hợp bị crash. Nếu bạn thấy số lượng reset tăng đột biến, hãy kiểm tra các sự kiện SIGKILL hoặc các đợt tăng vọt CPU trong các dịch vụ liên quan. Một tiến trình bị crash là nguyên nhân phổ biến nhất gây ra việc đóng socket "không sạch sẽ" (unclean).

Xác minh: Kiểm tra giải phápHãy mô phỏng lỗi trước khi nó xảy ra trong môi trường thực tế. Đừng phó mặc việc xử lý lỗi cho sự may rủi.

• Giả lập ngắt kết nối: Sử dụng tcpkill -i eth0 port 8080 để ép buộc ngắt kết nối và xác minh rằng cơ chế thử lại của bạn hoạt động.- Phân tích lưu lượng: Chạy ss -ant hoặc netstat trong khi test tải (load test). Quan sát các kết nối ở trạng thái CLOSE_WAIT hoặc LAST_ACK.- Kiểm tra áp lực (Stress Testing): Sử dụng Autocannon để gửi 10.000 yêu cầu. Nếu các lỗi reset chỉ xuất hiện khi bài test chậm lại, bạn đang gặp vấn đề không khớp timeout Keep-Alive.## Kiến trúc & Phòng ngừaMạng lưới đám mây hiện đại đòi hỏi việc lập kế hoạch IP và subnet chính xác. Các khối CIDR chồng chéo hoặc cấu hình sai NAT gateway có thể khiến các gói tin bị rơi vào "hố đen", dẫn đến lỗi reset khi thời gian chờ kết thúc. Khi thiết kế các VPC phức tạp hoặc gỡ lỗi lưu lượng truy cập xuyên vùng (cross-region), tôi dựa vào các công cụ trên trình duyệt để xác minh network mask. Subnet Calculator của ToolCraft là một công cụ tuyệt vời cho việc này—nó thực hiện các phép tính cục bộ, vì vậy các chi tiết hạ tầng nội bộ nhạy cảm của bạn không bao giờ rời khỏi máy tính. Cuối cùng, hãy luôn cập nhật môi trường của bạn. Kể từ Node.js 18, các giá trị mặc định cho keepAliveTimeout và headersTimeout đã được điều chỉnh để hoạt động tốt hơn với các bộ cân bằng tải đám mây, giúp giảm đáng kể tần suất xảy ra các lỗi này.