Khắc phục lỗi AWS ElastiCache Redis 111: Connection Refused trên cổng 6379

Khi ứng dụng của bạn không thể kết nối tới Redis

Bạn vừa triển khai một bản cập nhật quan trọng, nhưng thay vì một lần ra mắt suôn sẻ, các bản ghi log lại tràn ngập lỗi kết nối. Ứng dụng của bạn không thể giao tiếp với Redis. Bạn xác minh endpoint, kiểm tra AWS Console thấy trạng thái 'Available', nhưng client vẫn liên tục báo lỗi này:

Error 111 connecting to cluster.xxxxx.cache.amazonaws.com:6379. Connection refused.

Trên AWS, thông báo 'Connection Refused' thường báo hiệu rằng lớp mạng đang chủ động từ chối các gói tin của bạn. Khác với 'Timeout' thường ám chỉ việc gói tin bị bỏ rơi trong im lặng, lỗi 'Refused' thường có nghĩa là yêu cầu đã đến được đích nhưng bị từ chối. Điều này chỉ ra sự không khớp trong Security Group, tường lửa cục bộ hoặc sai lệch cấu hình TLS.

Cách khắc phục nhanh

Mở Amazon ElastiCache Console và chọn cluster của bạn.
Dưới tab Network & Security, xác định các VPC Security Groups được gắn với cluster.
Điều hướng tới EC2 Console -> Security Groups.
Tìm Security Group được sử dụng bởi Redis cluster của bạn (ví dụ: sg-redis-01234567).
Thêm một Inbound Rule:

Type: Custom TCP
- Port Range: 6379
- Source: Security Group ID của application server (ví dụ: sg-web-8899aabb) hoặc VPC CIDR cụ thể của bạn (ví dụ: 10.0.0.0/16).
Lưu quy tắc và kiểm tra kết nối ngay lập tức.

Tại sao kết nối thất bại

Các node Redis trong ElastiCache nằm hoàn toàn bên trong VPC của bạn. Chúng không có địa chỉ IP công cộng. Theo mặc định, AWS thực hiện chiến lược tường lửa 'từ chối tất cả' (deny-all). Redis cluster của bạn sẽ bỏ qua mọi lưu lượng truy cập trên cổng 6379 trừ khi bạn cho phép Security Group của ứng dụng truy cập một cách rõ ràng.

Các nguyên nhân phổ biến gây ra lỗi này bao gồm:

Sơ suất về Nhóm Mặc định: Sử dụng Security Group 'default' thiếu quy tắc cho cổng 6379.
Sự cô lập: Triển khai ứng dụng trong một subnet mới chưa được ủy quyền.
Cố gắng truy cập công cộng: Thử kết nối từ máy tính xách tay cá nhân. ElastiCache không thể truy cập qua internet công cộng nếu không có VPN hoặc SSH tunnel.

Các phương pháp khắc phục chi tiết

1. Liên kết Security Group (Chaining)

Việc fix cứng địa chỉ IP như 10.0.1.55/32 là mầm mống cho các sự cố trong tương lai. Thay vào đó, hãy sử dụng tham chiếu Security Group. Điều này cho phép bất kỳ instance nào mang Security Group 'Web' đều có thể kết nối, ngay cả khi Auto Scaling Group của bạn thêm hoặc bớt server.

# Cấu hình theo Best Practice:
# Security Group của Ứng dụng: sg-webapp-01234
# Security Group của Redis: sg-redis-56789

# Hành động:
# Trong Redis SG, thêm một inbound rule:
# Protocol: TCP | Port: 6379 | Source: sg-webapp-01234

2. Xử lý các vấn đề liên VPC (Cross-VPC)

Nếu ứng dụng của bạn nằm ở VPC-A và Redis nằm ở VPC-B, một quy tắc SG đơn giản sẽ không giải quyết được vấn đề. Bạn cần một cầu nối. Đầu tiên, hãy đảm bảo kết nối VPC Peering đang ở trạng thái 'Active'. Thứ hai, cập nhật Route Tables để cả hai VPC biết cách tìm thấy nhau qua gateway pcx-xxxx. Cuối cùng, đảm bảo Redis SG cho phép lưu lượng truy cập từ khối CIDR từ xa.

3. Xử lý Mã hóa khi truyền tải (TLS)

Nếu bạn đã bật 'Encryption in Transit' trong quá trình thiết lập, lệnh redis-cli tiêu chuẩn sẽ thất bại. Server mong đợi một cái bắt tay (handshake) bảo mật và sẽ từ chối kết nối văn bản thuần túy. Bạn phải bao gồm flag --tls.

# Lệnh này sẽ lỗi nếu TLS đang hoạt động:
redis-cli -h cluster.xxxxx.cache.amazonaws.com -p 6379

# Lệnh này bắt buộc đối với các cluster có mã hóa:
redis-cli -h cluster.xxxxx.cache.amazonaws.com -p 6379 --tls

Lưu ý rằng các phiên bản cũ của redis-cli (trước phiên bản 6) có thể không hỗ trợ flag này. Bạn có thể cần cài đặt stunnel hoặc nâng cấp các tiện ích của mình.

Cách xác minh đường truyền đã thông

Hãy ngừng việc khởi động lại dịch vụ ứng dụng. Sử dụng các lệnh sau từ EC2 instance của bạn để cô lập vấn đề.

Phương pháp A: Netcat

nc -zv cluster.xxxxx.cache.amazonaws.com 6379

Thông báo 'succeeded!' có nghĩa là cửa đã mở. Nếu nó bị treo, bạn đang gặp phải một rào cản về mạng.

Phương pháp B: Telnet

telnet cluster.xxxxx.cache.amazonaws.com 6379
# Trying 10.0.x.x...
# Connected to cluster.xxxxx.cache.amazonaws.com.

Phương pháp C: Redis Ping

redis-cli -h cluster.xxxxx.cache.amazonaws.com -p 6379 ping
# Kết quả mong đợi: PONG

Danh sách kiểm tra lỗi cuối cùng

Khớp VPC: Client và cluster có nằm trong cùng một VPC không? Nếu không, hãy kiểm tra cài đặt Peering hoặc Transit Gateway của bạn.
Độ chính xác của Cổng: Bạn có vô tình đưa cổng 6380 vào danh sách trắng thay vì 6379 không?
Source ID: Inbound Rule đã được thiết lập cụ thể cho Security Group ID của Client chưa?
Endpoints: Nếu Cluster Mode đang bật, bạn có đang kết nối tới Configuration Endpoint không?
NACLs: Kiểm tra Network Access Control Lists của bạn. Đây là các quy tắc không lưu trạng thái (stateless) và có thể chặn lưu lượng phản hồi đi ra ngay cả khi cổng đầu vào đã mở.