Gỡ lỗi các mã Cloudflare 1010 và 530 trong API tự host

Hai sự cố gián đoạn dịch vụ riêng biệt đã xảy ra trên cùng một điểm cuối API trong vòng hai mươi bốn giờ, gây nhầm lẫn cho đội ngũ kỹ sư. Vào ngày 19 tháng 10 năm 2026, một client Python nhận được phản hồi 403 Forbidden trong khi trình duyệt truy cập vào cùng URL đó mà không gặp vấn đề gì. Vài giờ sau, mọi hostname nằm sau đường hầm hạ tầng đều trả về lỗi 530, chỉ ra rằng kết nối tới máy chủ nguồn bị mất hoàn toàn mặc dù ứng dụng cục bộ vẫn đang chạy bình thường.

Chuyện gì đã xảy ra

Sự cố đầu tiên liên quan đến một script Python cố gắng truy cập vào điểm cuối MCP. Trang web tải thành công trên trình duyệt với trạng thái 200 OK, nhưng client tự động thất bại với lỗi 403 chứa nội dung "error code: 1010". Mã cụ thể này tương ứng với tính năng Browser Integrity Check (BIC) của Cloudflare, một tính năng bảo mật phân tích các đặc điểm của yêu cầu như dấu vân tay TLS, headers và chuỗi User-Agent. Vì client Python sử dụng User-Agent mặc định Python-urllib/3.x, Tường lửa Ứng dụng Web (WAF) đã phân loại nó là bot và chặn quyền truy cập trước khi yêu cầu kịp đến máy chủ ứng dụng. Client diễn giải trang lỗi HTML như một lỗi phân tích cú pháp JSON, che giấu nguyên nhân thực sự.

Sự cố thứ hai xảy ra sau đó trong ngày khi tất cả các hostname nằm sau Argo Tunnel bắt đầu trả về lỗi 530 kèm "error code: 1033". Trạng thái này cho thấy mạng biên của Cloudflare không thể kết nối với đường hầm nguồn. Dịch vụ cục bộ vẫn khỏe mạnh và phản hồi tốt trên 127.0.0.1, xác nhận rằng bản thân ứng dụng không có lỗi. Quá trình đường hầm đã thoát im lặng sau khi mất kết nối với mạng biên. Việc khôi phục trở nên phức tạp hơn do một phiên VPN cũ trên máy chủ đang định tuyến lưu lượng qua giao diện TUN với gateway IP giả, gây ra timeout bắt tay TLS với các máy chủ biên của Cloudflare. Chỉ khởi động lại đường hầm không đủ; đội ngũ phải khởi động lại client VPN trước để khôi phục định tuyến đúng cách.

Chi tiết chính

• Lỗi 1010 được kích hoạt bởi Browser Integrity Check khi một yêu cầu thiếu các chữ ký điển hình của trình duyệt, chẳng hạn như User-Agent hợp lệ hoặc dấu vân tay TLS.
• Lỗi 1033 với trạng thái HTTP 530 có nghĩa là bộ kết nối Argo Tunnel đã tắt hoặc không thể tiếp cận mạng biên Cloudflare, chứ không phải máy chủ nguồn bị sập.
• Các User-Agent mặc định của thư viện như python-requests hoặc python-urllib thường xuyên bị hệ thống bảo vệ chống bot gắn cờ trừ khi chúng được cho phép rõ ràng.
• Các kiểm tra sức khỏe cục bộ giám sát localhost sẽ bỏ sót các sự cố đường hầm vì ứng dụng vẫn chạy ngay cả khi điểm cuối công khai không thể truy cập.
• Các kết nối VPN cũ có thể chặn đứng lưu lượng hướng tới các dải IP của Cloudflare, gây ra timeout kết nối ngăn cản việc thiết lập lại đường hầm.
• Các đơn vị systemd được cấu hình với Restart=always tự động khôi phục các quá trình đường hầm bị crash, trong khi các lệnh nohup thủ công thì không.

Bối cảnh

Cloudflare đóng vai trò là một proxy ngược và mạng phân phối nội dung (CDN) nằm giữa người dùng và máy chủ tự host. Nó cung cấp các tính năng bảo mật như Tường lửa Ứng dụng Web (WAF) và các dịch vụ đường hầm như Argo Tunnel (cloudflared). WAF bao gồm Browser Integrity Check, tính năng xem xét kỹ lưỡng các yêu cầu đến để tìm kiếm dấu hiệu của tự động hóa. Nếu một yêu cầu trông giống script hơn là con người sử dụng trình duyệt, Cloudflare sẽ chặn nó bằng lỗi 1010. Điều này bảo vệ các trang web khỏi scraper và bot nhưng có thể vô tình chặn các client API hợp lệ nếu không được cấu hình đúng cách.

Argo Tunnel tạo một kết nối outbound an toàn từ máy chủ nguồn đến mạng biên của Cloudflare, loại bỏ nhu cầu mở các cổng inbound trên tường lửa. Tuy nhiên, sự phụ thuộc này có nghĩa là nếu quá trình đường hầm bị crash hoặc mất kết nối mạng, trang web sẽ trở nên không thể truy cập từ internet công khai ngay cả khi máy chủ cục bộ hoàn toàn khỏe mạnh. Hiểu rõ sự khác biệt giữa lỗi ở cấp độ ứng dụng và việc chặn ở cấp độ hạ tầng là rất quan trọng để gỡ lỗi hiệu quả.

Tại sao điều này quan trọng

Đối với các đội ngũ chạy phần mềm tự host, những sự cố này làm nổi bật một điểm mù phổ biến: chỉ thử nghiệm API thông qua trình duyệt web. Một dịch vụ hoạt động tốt trên Chrome có thể bị hỏng hoàn toàn đối với các công cụ tự động, pipeline CI/CD hoặc tích hợp bên thứ ba. Khi một client nhận được lỗi 1010, họ thấy một thông báo chung chung "access denied" (từ chối truy cập) có vẻ như là vấn đề cấu hình phía máy chủ. Nếu không kiểm tra body phản hồi thô, các nhà phát triển lãng phí thời gian gỡ lỗi mã ứng dụng thực tế chưa bao giờ được thực thi. Sự đánh lạc hướng này làm chậm quá trình giải quyết và xói mòn niềm tin vào độ tin cậy của API.

Tương tự, việc dựa vào các kiểm tra sức khỏe cục bộ mang lại cảm giác an toàn giả tạo trong các sự cố đường hầm. Nếu hệ thống giám sát chỉ ping localhost, chúng sẽ báo cáo trạng thái xanh trong khi người dùng bên ngoài gặp lỗi 530. Khoảng trống trong khả năng hiển thị này có nghĩa là các sự cố thường được khách hàng phát hiện thay vì các cảnh báo nội bộ. Đối với các công ty vừa và nhỏ quản lý hạ tầng của riêng mình, đảm bảo rằng giám sát xác thực toàn bộ đường dẫn công khai là điều cần thiết để duy trì thỏa thuận mức dịch vụ (SLA) và sự hài lòng của người dùng.

Bạn có thể làm gì

• Cấu hình các quy tắc WAF để bỏ qua Browser Integrity Check cho các đường dẫn API cụ thể, chẳng hạn như /api/*, để cho phép client máy móc trong khi vẫn bảo vệ các trang công khai.
• Tài liệu hóa và áp dụng các chuỗi User-Agent cụ thể cho client API, bao gồm thông tin phiên bản và URL liên hệ, để giảm thiểu dương tính giả.
• Tách biệt các hostname hướng tới công khai khỏi các điểm cuối API, sử dụng các subdomain riêng biệt như api.example.com với cài đặt bảo vệ bot lỏng lẻo hơn.
• Chạy các dịch vụ systemd cho bộ kết nối đường hầm với Restart=always để đảm bảo khôi phục tự động nếu quá trình bị crash hoặc thoát bất ngờ.
• Giám sát các URL công khai cho các kiểm tra sức khỏe thay vì các cổng cục bộ để phát hiện ngay lập tức các ngắt kết nối đường hầm và vấn đề DNS.
• Xác minh định tuyến mạng khi bắt tay đường hầm thất bại, kiểm tra các phiên VPN cũ hoặc quy tắc tường lửa chặn các dải IP của Cloudflare.