Cách khắc phục lỗi curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL

intermediate🔒 SSL/TLS2026-07-12| Linux (Ubuntu/CentOS/Debian), macOS hoặc Windows sử dụng curl với backend OpenSSL, thường xảy ra khi nằm sau proxy doanh nghiệp hoặc tường lửa hạn chế.

Error Message

curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to example.com:443
#curl#openssl#proxy#khắc phục lỗi

Vấn đề

Gặp lỗi SSL_ERROR_SYSCALL thường có nghĩa là kết nối bị ngắt đột ngột. Không giống như lỗi sai chứng chỉ (certificate mismatch) khi máy chủ báo "Tôi không tin bạn", lỗi này xảy ra khi kết nối bị đóng sầm lại trước khi quá trình bắt tay (handshake) mã hóa hoàn tất. Lệnh gọi hệ thống (system call) bên dưới—thường là read() hoặc write()—đã nhận được gói tin Reset (RST) hoặc EOF khi nó đang mong đợi dữ liệu.

Terminal của bạn thường sẽ hiển thị dòng thông báo gây khó chịu này:

curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to example.com:443

Nguyên nhân phổ biến

  • Proxy can thiệp: Một proxy doanh nghiệp có thể ngắt kết nối vì nó không nhận diện được giao thức SSL hoặc nó đang đợi xác thực nhưng không được phản hồi.
  • Middleboxes và DPI: Các tường lửa kiểm soát gói tin sâu (Deep Packet Inspection - DPI) thường loại bỏ lưu lượng mã hóa mà chúng không thể giải mã hoặc kiểm tra.
  • Nghẽn MTU: Nếu bạn đang sử dụng VPN, các gói tin của bạn có thể quá lớn so với đường truyền (tunnel), dẫn đến việc bị loại bỏ âm thầm.
  • Lỗi IPv6: curl có thể cố gắng kết nối với máy chủ qua IPv6 trong khi proxy của bạn chỉ hỗ trợ IPv4.

Các bước khắc phục

1. Ép sử dụng IPv4

Proxy thường gặp lỗi với địa chỉ IPv6. Ép curl chỉ sử dụng IPv4 là cách nhanh nhất để loại trừ các sai sót về DNS và định tuyến.

curl -4 -v https://example.com

2. Kiểm tra các biến môi trường Proxy

Các biến môi trường cấu hình sai là thủ phạm thường xuyên. Thiếu tiền tố http:// hoặc thừa dấu gạch chéo ở cuối chuỗi proxy có thể làm hỏng quá trình bắt tay. Hãy kiểm tra cài đặt hiện tại của bạn trước:

env | grep -i proxy

Nếu chúng không chính xác, hãy thiết lập lại theo định dạng chuẩn. Tránh thêm dấu gạch chéo sau số cổng (port):

export http_proxy="http://proxy.example.com:8080"
export https_proxy="http://proxy.example.com:8080"

Để bỏ qua hoàn toàn các vấn đề về môi trường cục bộ, hãy truyền trực tiếp proxy vào lệnh:

curl -x http://proxy.example.com:8080 -v https://example.com

3. Điều chỉnh MTU (Maximum Transmission Unit)

Các gói tin mạng không phải lúc nào cũng có cùng kích thước. Ethernet tiêu chuẩn sử dụng MTU 1500 byte, nhưng các header của VPN (như OpenVPN hoặc Cisco AnyConnect) sẽ làm giảm không gian khả dụng. Khi một gói tin vượt quá giới hạn, nó thường bị hủy, gây ra lỗi syscall. Hãy thử hạ MTU xuống 1400 hoặc 1300 để xem kết nối có ổn định không.

# Tìm interface đang hoạt động (ví dụ: eth0, en0, hoặc wlan0)
ip link show

# Tạm thời hạ MTU xuống 1400
sudo ip link set dev eth0 mtu 1400

Chạy lại lệnh curl. Nếu thành công, bạn đã xác nhận được vấn đề là do phân mảnh mạng.

4. Hạ cấp xuống TLS 1.2

Các phần cứng cũ và "thiết bị bảo mật" đời cũ thường gặp trục trặc với TLS 1.3. Ép curl sử dụng TLS 1.2 (cũ hơn nhưng tương thích rộng rãi hơn) có thể vượt qua các thiết bị trung gian khó tính này.

curl --tls-max 1.2 -v https://example.com

5. Cập nhật curl và OpenSSL

Các phiên bản OpenSSL cũ (như dòng 1.0.2) thiếu hỗ trợ cho các bộ mã hóa (cipher suites) hiện đại. Kiểm tra phiên bản của bạn bằng lệnh curl --version. Nếu bạn đang chạy phiên bản từ nhiều năm trước, đã đến lúc cập nhật các bản build mới nhất.

# Cho người dùng Ubuntu/Debian
sudo apt update && sudo apt install curl openssl

# Cho người dùng RHEL/CentOS
sudo yum update curl openssl

Xác minh

Sử dụng cờ verbose (-v) để kiểm tra quá trình bắt tay. Bạn cần thấy quá trình trao đổi chứng chỉ hoàn tất. Một kết nối khỏe mạnh sẽ kết thúc bằng dòng như sau:

* SSL connection using TLSv1.3 / AEAD-AES256-GCM-SHA384
* ALPN, server accepted to use h2

Nếu bạn thấy dòng "SSL connection using", bạn đã vượt qua lỗi syscall thành công.

Mẹo và Cách phòng ngừa

Các lỗi ở cấp độ mạng thường bắt nguồn từ cấu hình sai subnet hoặc các quy tắc tường lửa quá khắt khe. Khi tôi gỡ lỗi tại sao proxy từ chối lưu lượng cụ thể, tôi sử dụng Máy tính Subnet để kiểm tra lại ranh giới mạng của mình. Nó đảm bảo các dải IP được phép trong tường lửa thực sự khớp với các khối CIDR mà proxy sử dụng.

Một mẹo cuối cùng: nếu bạn bị chặn bởi một tường lửa rất nghiêm ngặt, hãy sử dụng --trace-ascii output.txt. Lệnh này tạo ra một bản dump hex đầy đủ của kết nối. Bạn có thể gửi tệp này cho quản trị viên mạng để chỉ ra chính xác gói tin nào (thường là Client Hello) đang bị chặn.

Related Error Notes