TL;DR: Cách sửa nhanh
Lỗi này thường bắt nguồn từ một sự nhầm lẫn đơn giản: Nginx đang phản hồi bằng giao thức HTTP thuần túy trong khi trình duyệt của bạn đang chờ đợi một cái bắt tay (handshake) mã hóa của HTTPS. Cách khắc phục phổ biến nhất là thêm tham số ssl vào chỉ thị listen.
# CÁCH SAI
server {
listen 443;
server_name example.com;
...
}
# CÁCH ĐÚNG
server {
listen 443 ssl;
server_name example.com;
ssl_certificate /path/to/cert.pem;
ssl_certificate_key /path/to/key.pem;
...
}
Sau khi cập nhật file, hãy chạy nginx -t để kiểm tra lỗi cú pháp và áp dụng các thay đổi bằng lệnh systemctl reload nginx.
Nguyên nhân thực sự gây ra lỗi SSL_ERROR_RX_RECORD_TOO_LONG là gì?
Dù bạn thấy lỗi SSL_ERROR_RX_RECORD_TOO_LONG trên Firefox hay ERR_SSL_PROTOCOL_ERROR trên Chrome, nguyên nhân gốc rễ đều là do sự không tương thích về giao thức. Trình duyệt của bạn gửi một "Client Hello" để bắt đầu quá trình bắt tay TLS, và hoàn toàn mong đợi một phản hồi đã được mã hóa.
Thay vào đó, máy chủ của bạn lại phản hồi bằng văn bản thuần túy (plain text)—thường là một trang lỗi 404 hoặc chuyển hướng 301. Trình duyệt cố gắng đọc vài byte đầu tiên của văn bản đó như là độ dài bản ghi TLS. Vì các ký tự ASCII như "HTTP" khi dịch sang nhị phân sẽ tạo ra những con số khổng lồ, trình duyệt giả định rằng bản ghi này quá lớn và chạm giới hạn cứng. Về mặt kỹ thuật, phản hồi đã vượt quá mức tối đa 16.384 byte của một bản ghi TLS tiêu chuẩn.
Các cách khắc phục phổ biến
1. Thêm tham số 'ssl' vào chỉ thị Listen
Nginx hoạt động rất máy móc. Nó sẽ không tự hiểu rằng cổng 443 cần mã hóa chỉ vì đó là tiêu chuẩn chung. Bạn phải bật bộ máy SSL một cách rõ ràng cho socket cụ thể đó.
server {
listen 443 ssl; # Tham số 'ssl' này là bắt buộc
server_name myapp.io;
ssl_certificate /etc/letsencrypt/live/myapp.io/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/myapp.io/privkey.pem;
# ... phần còn lại của cấu hình
}
2. Giải quyết xung đột Default Server
Nếu thư mục /etc/nginx/sites-enabled/ của bạn chứa nhiều tệp, một tệp trong số đó có thể đang đóng vai trò là default_server cho cổng 443 mà không bật SSL. Nginx có thể đang tiếp nhận yêu cầu của bạn trong khối "thuần túy" đó trước khi nó kịp đến được cấu hình trang web thực sự của bạn.
Kiểm tra toàn bộ cấu hình để tìm các trường hợp sử dụng cổng 443:
grep -r "443" /etc/nginx/sites-enabled/
Mọi khối server lắng nghe trên cổng 443 đều phải có tham số ssl. Nếu thiếu, bạn đã tìm thấy nguyên nhân rồi đó.
3. Tránh bẫy SSL trên cổng 80
Tôi đã thấy nhiều nhà phát triển vô tình ép SSL trên cổng 80 khi sao chép các mẫu cấu hình. Nếu cấu hình của bạn ghi listen 80 ssl; và bạn truy cập https://yourdomain.com (mặc định là cổng 443), bạn sẽ bị lỗi kết nối. Tuy nhiên, nếu truy cập https://yourdomain.com:80, lỗi độ dài bản ghi sẽ xuất hiện ngay lập tức.
4. Sửa vòng lặp chế độ "Flexible" của Cloudflare
Người dùng Cloudflare thường xuyên gặp lỗi này khi cài đặt SSL/TLS ở chế độ "Flexible." Trong chế độ này, Cloudflare giao tiếp với máy chủ Nginx của bạn qua cổng 80. Nếu cấu hình Nginx của bạn tự động chuyển hướng mọi lưu lượng cổng 80 sang HTTPS, bạn sẽ tạo ra một vòng lặp giao thức. Với bất kỳ máy chủ nào có chứng chỉ hợp lệ (như Let's Encrypt), hãy chuyển Cloudflare sang chế độ "Full (strict)" để đảm bảo mã hóa đầu cuối.
5. Kiểm tra logic Proxy Pass
Mặc dù ít phổ biến hơn, điều này có thể xảy ra nếu Nginx đóng vai trò là reverse proxy. Nếu bạn cố gắng proxy một yêu cầu HTTPS đến một backend chỉ hiểu HTTP—hoặc ngược lại—mà không xử lý đúng các header, phản hồi có thể bị lỗi. Thông thường, lỗi này xảy ra ngay trong kết nối đầu tiên giữa trình duyệt và Nginx.
Các bước xác minh
Bộ nhớ đệm của trình duyệt rất "lì lợm" và có thể che giấu kết quả sửa lỗi của bạn. Hãy sử dụng curl để xem chính xác máy chủ đang phản hồi gì.
Bước 1: Chạy thử nghiệm chi tiết
curl -v https://example.com
Quan sát đầu ra. Nếu bạn thấy TLS handshake, Client hello theo sau bởi 400 Bad Request hoặc một đoạn mã HTML thuần túy, sự không tương thích giao thức đã được xác nhận.
Bước 2: Ép HTTP trên cổng SSL
Kiểm tra xem máy chủ có đang phản hồi sai văn bản thuần túy trên cổng bảo mật hay không:
curl http://example.com:443
Nếu lệnh này trả về 200 OK hoặc 301 Redirect, chắc chắn cấu hình Nginx của bạn đang bị lỗi. Nó không được phép phản hồi HTTP thuần túy trên cổng 443.
Bước 3: Xác nhận tiến trình
sudo ss -tulpn | grep :443
Hãy đảm bảo nginx là tiến trình thực sự đang lắng nghe trên cổng đó, chứ không phải một dịch vụ lạ hoặc một Docker container đang chiếm dụng cùng cổng trên host.
Tài liệu tham khảo thêm
- [Tài liệu chính thức của Nginx: Cấu hình HTTPS](https://nginx.org/en/docs/http/configuring_https_servers.html)
- [Let's Encrypt: Sử dụng Certbot với Nginx](https://letsencrypt.org/docs/getting-started/)