ERR_ là gìTUNNEL_CONNECTION_FAILED?

Scrapeless Proxies định tuyến các yêu cầu của khách hàng thông qua những cổng được ghi chép cho việc thu thập web dựa trên proxy.

ERR_TUNNEL_CONNECTION_FAILED có nghĩa là Chromium không thể thiết lập một đường hầm qua proxy cho kết nối được yêu cầu. Đối với một yêu cầu HTTPS đi qua một proxy HTTP, hãy kiểm tra phiên trao đổi CONNECT và phản hồi của nó. Thông báo xác định giai đoạn đường hầm bị lỗi; bản thân nó không tự phân biệt lỗi xác thực, giới hạn điểm đến và các vấn đề kết nối thượng nguồn.

Phiên trao đổi CONNECT tạo ra đường hầm

Một đường hầm cho phép máy khách mang một giao thức khác đi qua một proxy HTTP. Đối với HTTPS thông thường qua một proxy HTTP, máy khách trước hết yêu cầu proxy mở kết nối tới authority đích. Sau một phản hồi đường hầm thành công, máy khách có thể trao đổi các byte TLS với đích qua kết nối đó.

Đặc tả phương thức HTTP CONNECT định nghĩa việc chuyển đổi thành công sang chế độ đường hầm. Phản hồi của proxy thuộc về phiên thiết lập đường hầm. Nó tách biệt với phản hồi HTTP về sau mà đích có thể gửi bên trong kết nối đã mã hóa. Giữ các phản hồi đó tách biệt là bước đầu tiên để chẩn đoán lỗi này.

Một lỗi đường hầm có thể xảy ra ngay cả khi trình duyệt đã kết nối tới một dịch vụ biết nói giao thức proxy. Dịch vụ có thể từ chối đích, yêu cầu xác thực, hoặc không tạo được kết nối đi tiếp. Trình duyệt thường chỉ hiển thị một chuỗi lỗi cấp cao thay vì một lời giải thích thân thiện với người vận hành. Hãy giữ lại mọi chi tiết thương lượng mà máy khách hoặc cổng cho sẵn.

Định nghĩa lỗi đường hầm của Chromium xác định một đường hầm không thể được thiết lập. Nó không nên được hiểu như một chẩn đoán đầy đủ về tình trạng ngừng hoạt động của đích. Hãy ghi lại gateway, host và cổng đích được yêu cầu, cùng phản hồi hoặc sự kiện đường hầm được quan sát lần cuối. Các trường đó xác định ranh giới chính xác hơn so với thông báo hiển thị trên trang.

Phân biệt phản hồi CONNECT với phản hồi từ đích

Chặng trả lời quyết định ý nghĩa của một trạng thái HTTP trong quá trình điều tra proxy. Một phản hồi với CONNECT đến từ phiên trao đổi với proxy, trong khi phản hồi ứng dụng sau khi có TLS với đích thuộc về đường đi yêu cầu phía đích. Cùng một loại mã số có thể dẫn tới nhầm lẫn về đơn vị chịu trách nhiệm sự cố.

Nếu proxy yêu cầu xác thực, hãy xem xét thử thách của proxy và cấu hình thông tin xác thực được hỗ trợ. Nếu nó từ chối đích, hãy xem xét chính sách đích và cổng của gateway. Nếu gateway không thể có được kết nối đi tiếp, nhật ký của chính nó có thể chứa chi tiết về DNS, tuyến đường hoặc listener mà trình duyệt không hiển thị.

Phần triển khai socket proxy HTTP của Chromium cho thấy vì sao việc thiết lập đường hầm có cơ chế xử lý phản hồi riêng. Các phản hồi xác thực và phản hồi đường hầm không được hỗ trợ có thể đi theo những nhánh xử lý khác nhau. Tránh quy tắc đơn giản hóa rằng mọi phản hồi không thành công đều sinh ra chính xác cùng một mã trong trình duyệt trong mọi ngữ cảnh.

Đừng loại bỏ phản hồi CONNECT chỉ vì bộ thu thập muốn trạng thái từ đích. Hãy giữ các trường riêng cho thương lượng proxy và phản hồi từ đích. Nếu đường hầm chưa bao giờ mở, phản hồi đích nên để trống thay vì nhận trạng thái của proxy như thể website đã phục vụ nó.

Giao thức Gateway và cổng đích là những lựa chọn tách biệt

Kết nối proxy cần kiểu truyền tải và giao thức được gateway ghi chép. Scheme của đích không tự động chọn scheme của proxy. Một proxy HTTP có thể mang HTTPS bằng cách thiết lập đường hầm, trong khi một kết nối TLS tới gateway là một lựa chọn cấu hình khác.

Hãy kiểm tra cấu hình máy khách và giao thức proxy được hỗ trợ cùng nhau. Một scheme gateway sai có thể ngăn một phiên trao đổi CONNECT có ý nghĩa. Một listener SOCKS không thể hoán đổi với một listener proxy HTTP chỉ vì cả hai đều định tuyến lưu lượng. Hãy dùng đúng loại proxy mà máy khách và nhà cung cấp hỗ trợ.

Các cổng đích có thể bị giới hạn bởi chính sách proxy. Một website HTTPS công khai trên cổng bảo mật thông thường của nó có thể hoạt động trong khi một ứng dụng trên cổng tùy chỉnh bị từ chối. Một đích kiểm soát hoạt động do đó chỉ chứng minh một đường hầm được phép, không phải quyền cho mọi authority. Hãy cung cấp host và cổng đích cho chủ sở hữu gateway khi yêu cầu chẩn đoán.

Cấu hình endpoint proxy và thông tin xác thực Scrapeless hiện tại là nguồn xác thực cho việc thiết lập kênh. Sao chép các giá trị endpoint được hỗ trợ và cấu trúc thông tin xác thực được sinh ra của kênh. Điều này thiết lập một cấu hình đã biết cho cuộc điều tra mà không khẳng định rằng bất kỳ đích cụ thể nào phải truy cập được.

Kiểm tra Giai đoạn Tunnel mà không gây nhầm lẫn giữa các lớp

Một cuộc kiểm tra tunnel có kiểm soát giữ nguyên cấu hình client, gateway và xác thực. So sánh một đích điều khiển HTTPS công khai được cho phép với đích bị ảnh hưởng. Ghi lại kết quả của phiên trao đổi CONNECT cho từng trường hợp. Nếu tunnel điều khiển mở, chính sách theo đích hoặc kết nối tiếp theo vẫn là một giả thuyết hữu ích cho host bị ảnh hưởng.

Một yêu cầu điều khiển HTTP thuần kiểm tra hành vi chuyển tiếp, nhưng không thiết lập tunnel HTTPS. Nếu chuyển tiếp HTTP hoạt động trong khi tunnel HTTPS bị lỗi, hãy kiểm tra hỗ trợ CONNECT, cách xử lý xác thực trong quá trình thiết lập tunnel và chính sách theo đích. Tránh kết luận từ so sánh đó rằng mọi chứng chỉ trên mục tiêu đều không hợp lệ.

Khi cả điều khiển và mục tiêu đều thất bại ở bước thiết lập tunnel, hãy kiểm tra cấu hình dùng chung trước logic trang mục tiêu. Kiểm tra proxy đã chọn, nguồn thông tin xác thực và giao thức. Nếu thiết lập giữa client và nhà cung cấp khớp nhau, hãy thu thập bằng chứng thương lượng để hỗ trợ. Đừng bù đắp cho một vấn đề tunnel chưa được xác nhận bằng cách thay đổi bộ chọn HTML hoặc thời gian chờ render.

Khi tunnel đã thiết lập thành công, đánh dấu giai đoạn đó là hoàn tất và kiểm tra giai đoạn tiếp theo một cách độc lập. Mục tiêu sau đó có thể lỗi ở bước xác minh danh tính TLS, thương lượng bảo mật hoặc yêu cầu ứng dụng. Một lỗi xảy ra sau đó không có nghĩa là tunnel trước đó chưa từng được thiết lập. Bản ghi thu thập nên giữ lại trình tự này.

So sánh lỗi Tunnel với các lỗi tương tự

Phân biệt theo giai đoạn hữu ích hơn là một danh sách chung các cách sửa lỗi trình duyệt. Mỗi quan sát sau đây gợi ý một tập bằng chứng khởi đầu khác nhau.

Lỗi kết nối gateway xảy ra trước phiên trao đổi proxy HTTP. Một yêu cầu xác thực proxy cho thấy một ranh giới xác thực đang phản hồi. Lỗi thiết lập tunnel hướng sự chú ý tới thương lượng CONNECT. Vấn đề chứng chỉ sau khi tunnel mở liên quan đến danh tính và độ tin cậy của đầu cuối bảo mật đang được xác minh.

Một số công cụ client bao bọc các lỗi này trong những ngoại lệ yêu cầu rộng hơn. Hãy dùng các trường chẩn đoán được tài liệu hóa của chúng và giữ lại sự kiện thô bên dưới. Loại công việc đã chuẩn hóa của bạn có thể ghi là "proxy tunnel không khả dụng" mà không bịa ra phản hồi HTTP từ đích hoặc một nguyên nhân mạng đã được xác nhận.

Bảo vệ danh tính phiên thu thập khi không thể mở tunnel

Một tunnel không thành công chưa phân phối được biểu diễn mục tiêu được yêu cầu. Bộ thu thập nên tạo một sự kiện chẩn đoán mạng và không chấp nhận nội dung nguồn. Một trang lỗi proxy, nếu có, thuộc về phiên trao đổi với proxy chứ không phải trang bài viết hoặc sản phẩm của đích.

Đừng âm thầm chọn một tuyến khác khi tunnel bắt buộc bị lỗi. Thay đổi tuyến có thể làm thay đổi giá theo vùng, khả năng truy cập nội dung và hành vi xác thực. Một tuyến thay thế được kiểm soát là hữu ích khi được cho phép rõ ràng và được ghi lại; việc thay thế tuyến một cách vô hình khiến tập dữ liệu kết quả khó diễn giải hơn.

Tách chi tiết gateway khỏi các giá trị thông tin xác thực bí mật. Giữ lại endpoint của nhà cung cấp, tham chiếu kênh đã làm sạch, authority được yêu cầu và loại phản hồi. Làm mờ tiêu đề ủy quyền và các tham số URL nhạy cảm trước khi xuất trace. Nhà vận hành gateway cần đủ thông tin để tìm phiên trao đổi, chứ không cần mật khẩu đã cấp quyền.

Phần So sánh đường hầm HTTPS và kiểm tra TLS giải thích một ranh giới liên quan: một tunnel có thể mang lưu lượng đã mã hóa mà bản thân nó không phải là dịch vụ giải mã. Sản phẩm Scrapeless proxy cung cấp hạ tầng định tuyến, trong khi gói proxy hiện tại giúp đánh giá nhu cầu lưu lượng. Cả gói dịch vụ lẫn thay đổi IP đều không sửa được chứng chỉ hoặc logic đăng nhập của mục tiêu.

Một cách xử lý tunnel hữu ích trông như thế nào

Một cách xử lý hữu ích nêu rõ kết quả CONNECT và cấu hình hoặc chính sách nào đã được chỉnh sửa để thay đổi nó. Nếu gateway từ chối một đích theo thiết kế, việc phê duyệt tuyến thuộc về chủ sở hữu chính sách. Nếu thông tin xác thực được cung cấp sai, hãy sửa đường dẫn xác thực trên client. Nếu kết nối tiếp theo bị lỗi, hãy dùng bằng chứng phía gateway để định vị nó.

Sau khi tunnel mở, hãy hoàn tất xác thực TLS và nội dung trước khi chấp nhận một phiên thu thập. Đây là tiêu chí hoàn tất mạnh hơn việc làm cho trình duyệt ngừng hiển thị ERR_TUNNEL_CONNECTION_FAILED. Nó xác lập rằng nguồn dự định đã được truy cập qua tuyến bắt buộc.