HTTP 522 Connection Timed Out (Cloudflare)

Scrapeless Web Unlocker truy xuất nội dung trang công khai cho các quy trình làm việc cần phân biệt lỗi kết nối tới origin với các kết quả có thể sử dụng được.

HTTP 522 Connection Timed Out là lỗi Cloudflare báo cáo việc hết thời gian chờ khi liên hệ với máy chủ web gốc (origin). Trình duyệt của bạn có thể đã kết nối tới Cloudflare thành công dù Cloudflare không hoàn tất được quá trình trao đổi kết nối bắt buộc với máy chủ phía sau. Vì vậy việc khắc phục thường thuộc về nhà vận hành website hoặc nhà cung cấp hosting.

Vị trí xảy ra 522 trong đường đi của yêu cầu

Một 522 xảy ra trên phần Cloudflare‑tới‑origin của đường đi yêu cầu. Khách truy cập trước hết giao tiếp với Cloudflare; sau đó Cloudflare cần giao tiếp với origin phục vụ website. Lỗi trên phần thứ hai có thể tạo ra một trang lỗi vẫn đến được với khách truy cập một cách bình thường. Việc nhận được trang đó chứng minh khách truy cập đã nhận được một phản hồi HTTP, nhưng không chứng minh origin đã xử lý thao tác được yêu cầu.

Định nghĩa Cloudflare 522 xác định hai trường hợp liên quan: hết thời gian chờ trước khi thiết lập kết nối TCP và thiếu xác nhận sau khi đã thiết lập kết nối. Đây là các quan sát ở tầng truyền tải. Đừng diễn giải trường hợp thứ hai thành khẳng định rằng ứng dụng chỉ đơn thuần mất quá nhiều thời gian để tạo phản hồi đầy đủ; việc xác nhận và việc ứng dụng hoàn thành là các sự kiện khác nhau.

Nhật ký truy cập ứng dụng có thể không chứa mục khớp nào nếu yêu cầu chưa bao giờ đến được tầng ứng dụng. Sự vắng mặt đó chỉ hữu ích khi đi kèm với các bằng chứng khác. Nó có thể cho thấy lỗi kết nối, lỗ hổng ghi log, hoặc yêu cầu đã được gửi tới một origin khác. Hãy kiểm tra đích đến và phạm vi ghi log trước khi quyết định lời giải thích nào phù hợp.

522 Khác Gì Với Các Lỗi Lân Cận

Trạng thái HTTP và ngoại lệ cục bộ mô tả các ranh giới khác nhau. Tiêu chuẩn HTTP semantics định nghĩa các trạng thái chung cho gateway và máy chủ, trong khi 522 là mã chẩn đoán riêng của Cloudflare. Giữ rõ phân biệt đó trong hồ sơ sự cố của bạn giúp chuyển vấn đề tới đúng bên chịu trách nhiệm.

Một sự cố đơn lẻ có thể tạo ra nhiều triệu chứng. Một client thu thập với thời hạn ngắn có thể ngừng chờ trước khi Cloudflare trả về 522. Một client khác với thời hạn dài hơn có thể nhận được tài liệu lỗi. Những quan sát đó có thể mô tả cùng một sự cố ngưng dịch vụ bên dưới mà không thuộc cùng một loại lỗi.

Kiểm Tra Địa Chỉ Origin Trước Khi Thay Đổi Công Suất

Địa chỉ origin được cấu hình phải khớp với máy chủ hiện đang được cấp phát để xử lý website. So sánh cấu hình DNS của Cloudflare với địa chỉ hiện tại của nhà cung cấp hosting và môi trường mong đợi. Việc di chuyển gần đây, thay thế instance, hoặc chỉnh sửa DNS có thể khiến lưu lượng vẫn được gửi tới một đích cũ.

Xác minh hostname và cổng mà origin mong đợi. Máy chủ trực tuyến là chưa đủ nếu thiếu listener cần thiết hoặc virtual host dự định không được phục vụ. Khi thực hiện kiểm tra trực tiếp tới origin được ủy quyền, hãy giữ nguyên hostname và yêu cầu TLS đúng; một bài kiểm tra chỉ dùng IP có thể tác động đến virtual host khác và tạo ra bằng chứng gây hiểu nhầm.

Giữ phạm vi hẹp. Nếu một hostname lỗi trong khi hostname khác hoạt động, hãy so sánh ánh xạ origin và cấu hình định tuyến của chúng thay vì giả định toàn bộ nền tảng hosting không khả dụng. Nếu nhiều site không liên quan cùng nằm trên một origin bị lỗi đồng thời, thì bằng chứng về mạng hoặc tài nguyên dùng chung trở nên liên quan hơn.

Kiểm Tra Tường Lửa Và Các Bộ Điều Khiển Mạng Hosting

Kiểm tra tường lửa phải xác định liệu các kết nối từ Cloudflare có đến được origin và nhận được phản hồi mong đợi hay không. Xem lại tường lửa trên host, security group, bộ lọc của nhà cung cấp hosting và bất kỳ hệ thống chặn tự động nào trên đường đi. Một cơ chế kiểm soát ở lớp mạng ngoài có thể loại bỏ lưu lượng trước khi hệ điều hành ghi nhận một yêu cầu ứng dụng.

Khi kiến trúc yêu cầu Cloudflare truy cập đến origin, hãy xác minh rằng các dải địa chỉ Cloudflare hiện tại đang được xử lý bởi đúng chính sách dự kiến. Không được thay thế một chính sách cụ thể bằng quyền truy cập công khai không hạn chế như một lối tắt chẩn đoán. Hãy yêu cầu nhà cung cấp hosting xác định nguồn, đích, hành động và timestamp của các gói bị chặn liên quan.

So sánh lịch sử cấu hình với khoảng thời gian đầu tiên bị lỗi. Một lần cập nhật rule trùng với thời điểm mất dịch vụ là một manh mối, không phải bằng chứng. Tìm lưu lượng khớp trong log hoặc bằng chứng gói tin, sau đó thử nghiệm bản chỉnh sửa nhỏ nhất nhưng hợp lý. Ghi lại lý do tồn tại của rule để lần dọn dẹp sau này không vô tình đưa lại hạn chế đó.

Điều tra một Origin đang chạy nhưng không phản hồi

Một origin đang chạy vẫn có thể không chấp nhận hoặc không xác nhận kết nối kịp thời khi tài nguyên hoặc đường truyền mạng của nó bị giới hạn. Hãy kiểm tra số lượng kết nối, tình trạng listener, áp lực CPU, áp lực bộ nhớ và các quan sát về mạng từ nhà cung cấp hosting. Kiểm tra xem lỗi ảnh hưởng đến kết nối mới, kết nối hiện có, hay chỉ một tập con đường dẫn.

Chỉ số ứng dụng đơn thuần có thể bỏ sót vấn đề. Một dashboard cho thấy lưu lượng yêu cầu thấp có thể có nghĩa ứng dụng còn dư công suất, hoặc có thể có nghĩa là yêu cầu không đến được với nó. Hãy ghép telemetry của ứng dụng với các chỉ số về transport và host để lưu lượng thấp không bị nhầm với dịch vụ khỏe mạnh.

Cấu hình keep-alive là một chi tiết phía origin khác cũng đáng kiểm tra so với yêu cầu của triển khai. Tránh thay đổi nhiều thiết lập transport cùng lúc. Một thay đổi được kiểm thử hẹp sẽ tạo ra bằng chứng dễ diễn giải, trong khi thay đổi đồng thời DNS, rule firewall và năng lực máy chủ sẽ khiến khó biết điều gì đã sửa được đường kết nối.

Sử dụng Timeline để kết nối bằng chứng từ trình duyệt và origin

Một timeline cần thể hiện khi nào khách truy cập bắt đầu điều hướng, khi nào Cloudflare trả về lỗi, và origin đã ghi nhận điều gì trong khoảng thời gian đó. Thời gian phía trình duyệt và phía máy chủ mô tả các góc nhìn khác nhau. Mô hình Navigation Timing giúp phân biệt các giai đoạn điều hướng, nhưng thời gian phía trình duyệt đơn thuần không thể hé lộ mọi trao đổi giữa Cloudflare và origin.

Ghi rõ múi giờ cùng với timestamp trong hệ thống sự cố. Liên hệ mã định danh yêu cầu trên trang lỗi (khi có) với hostname liên quan và log của origin. Nếu đồng hồ không được đồng bộ, hãy nói rõ điều đó thay vì khẳng định một sự trùng khớp chính xác giữa các sự kiện diễn ra trên những máy khác nhau.

So sánh một khoảng thời gian bị lỗi với một khoảng đã biết là thành công dưới cùng cấu hình định tuyến. Ghi nhận các thay đổi về đích, mức độ thành công của kết nối và tình trạng host. Một lần tải trang thành công đơn lẻ không chứng minh được origin đã khỏe mạnh trong suốt giai đoạn bị ảnh hưởng, đặc biệt khi có nhiều origin hoặc nhiều tuyến địa lý liên quan.

Những gì khách truy cập và trình thu thập dữ liệu nên lưu lại

Khách truy cập nên lưu lại đủ bằng chứng để nhà vận hành trang web điều tra đường đi đến origin. Bao gồm địa chỉ bị ảnh hưởng, mã lỗi, thời gian xấp xỉ và mã định danh yêu cầu hiển thị trên trang. Báo cáo xem sự cố ảnh hưởng đến toàn bộ trang hay một thao tác cụ thể, mà không để lộ các tham số query riêng tư hoặc thông tin xác thực.

Các trình thu thập dữ liệu nên giữ kết quả 522 bên ngoài tập dữ liệu mục tiêu. Nếu nhiệm vụ là thu thập giá sản phẩm, một tài liệu HTML trông hợp lệ với thương hiệu Cloudflare không đáp ứng nhiệm vụ đó. Hãy lưu lại một lỗi đã được phân loại và giữ bất kỳ mức giá cũ nào kèm nguyên thời điểm thu thập ban đầu. Điều này bảo toàn sự khác biệt giữa dữ liệu hiện tại bị thiếu và một mức giá thật sự không đổi.

Quy trình Cloudflare content-validation workflow có liên quan đến ranh giới chấp nhận này. Hãy kiểm tra danh tính trang và các trường bắt buộc sau khi truyền tải hoàn tất. Xử lý lỗi tại thời điểm thu thập chỉ hữu ích nếu các hệ thống dùng dữ liệu phía sau có thể phân biệt một quan sát bị thiếu với một bản ghi được chấp nhận.

Web Unlocker không sửa chữa được máy chủ Origin

Web Unlocker có thể cung cấp khả năng lấy nội dung được quản lý cho các quy trình trang công khai, nhưng không thể sửa lại ánh xạ DNS của trang web, mở lại firewall của nó, hoặc khôi phục năng lực của origin. Những kiểm soát đó thuộc về nhà vận hành. Vai trò của nó trong điều tra 522 bị giới hạn ở đường truy xuất và bằng chứng có được từ yêu cầu đó.

Xem lại Web Unlocker introduction trước khi quyết định liệu việc lấy nội dung đã render có phù hợp với nhiệm vụ thu thập hay không, và sử dụng Scrapeless pricing hiện tại cho việc lập kế hoạch khối lượng công việc. Giữ kết quả ở cấp độ dịch vụ tách biệt với kết quả của trang mục tiêu bất cứ khi nào hợp đồng phản hồi phân biệt chúng. Một lần trao đổi API hoàn tất không tự động khẳng định việc thu thập trang mục tiêu là thành công.

Xác định điều kiện dừng việc thu thập khi nguồn không khả dụng. Tiếp tục nhận thêm công việc nhắm vào một origin đang gặp sự cố có thể lãng phí tài nguyên và che khuất những bằng chứng hữu ích đầu tiên. Chỉ tiếp tục thu thập bình thường theo chính sách vận hành của bạn sau khi bên chịu trách nhiệm đã xác nhận rằng nguồn có thể phục vụ lưu lượng dự kiến.

Kết luận

Điều tra HTTP 522 bắt đầu từ đường kết nối đến origin. Hãy xác nhận đích, kiểm tra các kiểm soát mạng, và đối chiếu bằng chứng về transport với tình trạng host. Khách truy cập và trình thu thập dữ liệu nên cung cấp một bản ghi sự cố súc tích và lưu lại chính xác các lần không truy cập được; nhà vận hành trang và nhà cung cấp hosting phải sửa chữa vấn đề giao tiếp origin cơ bản.