ERR_CONNECTION_RESET là gì?
Scrapeless Agent Browser cung cấp các phiên trình duyệt được quản lý để điều hướng và thu thập nội dung từ các trang web động.
ERR_CONNECTION_RESET là một lỗi mạng của Chromium cho biết rằng kết nối đã bị đặt lại trong khi đang thực hiện một yêu cầu. Trình duyệt có bằng chứng về kết nối, nhưng lỗi hiển thị không xác định được thành phần máy chủ, proxy hoặc mạng cục bộ chịu trách nhiệm. Hãy chẩn đoán yêu cầu và tuyến bị ảnh hưởng trước khi thay đổi dữ liệu trình duyệt hoặc cài đặt mạng.
Tóm tắt ngắn
- ERR_CONNECTION_RESET mô tả một sự gián đoạn truyền tải đột ngột trong quá trình yêu cầu của trình duyệt.
- Lỗi tài liệu chính và lỗi tài nguyên nền có thể gây ra những ảnh hưởng khác nhau lên trang hiển thị.
- So sánh giữa các hồ sơ, thiết bị và đường dẫn mạng đã được phê duyệt giúp thu hẹp phạm vi nhưng tự thân chúng không xác định được nguyên nhân.
- Một ngoại lệ điều hướng trong tự động hóa phải được giữ tách biệt khỏi nội dung mục tiêu đã trích xuất thành công.
Những gì trình duyệt biết về lần reset
ERR_CONNECTION_RESET xác định một lần đặt lại trong ngăn xếp mạng của Chromium. Các định nghĩa lỗi kết nối của Chromium liên kết connection reset với hành vi TCP reset. Nhãn này cụ thể hơn so với thông báo chung “trang bị lỗi”, nhưng nó vẫn chỉ là một triệu chứng do phía khách quan sát được.
Một trang trình duyệt bao gồm nhiều hơn tài liệu chính. Hình ảnh, script, frame và các yêu cầu dữ liệu nền đều có thể có kết nối và lỗi riêng. Việc reset trên một yêu cầu script có thể để lại khung ứng dụng hiển thị trong khi nội dung chính không bao giờ xuất hiện. Việc reset trên tài liệu chính có thể chặn hoàn toàn điều hướng. Hãy ghi lại tài nguyên nào bị lỗi trước khi rút ra kết luận về toàn bộ trang.
Phần hiển thị của trình duyệt cũng tách biệt với phản hồi của trang web. Màn hình lỗi do trình duyệt tạo là đầu ra chẩn đoán cục bộ. Tiêu đề và phần giải thích của nó không phải là nội dung do đích trả về. Nếu một bộ thu thập trích xuất màn hình lỗi, nó có thể vô tình tạo ra một tài liệu về lỗi kết nối dưới URL mục tiêu. Việc ghi nhận phải phân biệt trạng thái lỗi của trình duyệt với một biểu diễn từ đích.
Đối với một trang web do bạn sở hữu, hãy bắt đầu với URL chính xác và loại tài nguyên. Ghi lại chuỗi lỗi của trình duyệt, việc có xuất hiện header phản hồi hay không, và đường dẫn proxy hoặc VPN đã chọn. Thông tin này cung cấp cho người vận hành một yêu cầu để đối chiếu với log ở lớp biên hoặc nguồn. “Trang web bị sập” là quá chung để trở thành một báo cáo sự cố hữu ích.
Giới hạn phạm vi lỗi qua ranh giới trình duyệt và mạng
Một chẩn đoán trình duyệt hữu ích thay đổi một điều kiện quan sát được tại một thời điểm. Hãy bắt đầu bằng cách so sánh với một trang đã được cấp quyền khác trên cùng host và một host công khai không liên quan. Lỗi chỉ giới hạn ở một đường dẫn tài nguyên gợi ý một hướng điều tra khác với lỗi xảy ra trên mọi điều hướng HTTPS. Giữ kết quả trong một bản ghi so sánh ngắn.
Khi khả thi, hãy so sánh cùng URL trong một hồ sơ trình duyệt sạch. Thành công ở đó thu hẹp phạm vi xuống các điều kiện khác biệt giữa các hồ sơ: tiện ích mở rộng, trạng thái lưu trữ, cài đặt proxy hoặc áp dụng chính sách. Nó không chứng minh rằng cookie gây ra TCP reset. Một hồ sơ đã xác thực có thể tạo ra một yêu cầu khác, và yêu cầu đó có thể gặp cách xử lý máy chủ khác.
Một thiết bị thứ hai trên cùng mạng giúp tách các điều kiện đặc thù của thiết bị khỏi định tuyến dùng chung. Một so sánh được phép trên mạng khác sau đó kiểm tra ranh giới mạng ban đầu. Chỉ sử dụng các phép thử này trong các đường dẫn truy cập đã được phê duyệt; một thiết bị được quản lý có thể yêu cầu cổng thông tin doanh nghiệp cho mọi yêu cầu.
Giữ nguyên các kiểm soát bảo mật bắt buộc trong quá trình chẩn đoán. Yêu cầu chủ sở hữu mạng kiểm tra một đích bị chặn hoặc một sự kiện kiểm tra khi bằng chứng chỉ ra đó là nơi vấn đề. Tắt rộng rãi các biện pháp bảo vệ sẽ loại bỏ cả chính sách và ngữ cảnh chẩn đoán. Một phép so sánh được phê duyệt hẹp hoặc việc quản trị viên xem log mang lại kết quả dễ diễn giải hơn.
Diễn giải thời điểm reset và việc hoàn tất yêu cầu
Thời điểm reset giúp quyết định nơi cần thu thập bằng chứng tiếp theo. Gián đoạn trước các header phản hồi hướng sự chú ý đến quá trình thiết lập kết nối, TLS, đàm phán proxy hoặc xử lý yêu cầu. Gián đoạn sau header hướng sự chú ý đến việc hoàn tất truyền tải và các thành phần phục vụ phần thân.
Đặc tả kết thúc kết nối TCP tách biệt reset termination khỏi việc đóng kết nối một cách có trật tự. Một bản ghi vết gói tin có thể hiển thị sự kiện này, nhưng vết ở phía client có thể chỉ nhìn thấy ranh giới mạng gần nhất. Một load balancer có thể chấm dứt kết nối client trong khi vẫn duy trì một kết nối nguồn khác. Hai bản ghi vết, khi được cho phép và sẵn có, có thể cho thấy những khác biệt mà một bản ghi duy nhất không thể.
Đối với các dịch vụ do bạn sở hữu, hãy căn chỉnh dấu thời gian trình duyệt với log máy chủ và các sự kiện triển khai. Tìm một kết nối kết thúc trong khi một instance đang được drain, một yêu cầu chạm tới chính sách giới hạn kích thước thân, hoặc một tuyến chọn một backend không khỏe mạnh. Đây là các ví dụ về giả thuyết mà log có thể xác nhận. Không điều nào tự động suy ra từ văn bản lỗi của trình duyệt.
Nếu lỗi xảy ra sau một khoảng thời gian nhàn rỗi, hãy so sánh một điều hướng mới với phiên bị ảnh hưởng và xem xét việc tái sử dụng kết nối. Nếu nó xảy ra sau một tài nguyên cụ thể, hãy so sánh tuyến và quá trình sinh phản hồi của tài nguyên đó với một tài nguyên hoạt động bình thường. Mục tiêu là đặt tên cho ranh giới lỗi nhỏ nhất, chứ không phải thu thập các lệnh reset của trình duyệt không liên quan.
Reset trình duyệt, lỗi HTTP và lỗi render
Một lần reset kết nối khác với một phản hồi HTTP và khác với một trang tải xong nhưng không render được nội dung có ý nghĩa. Các ngữ nghĩa phản hồi HTTP chỉ gán ý nghĩa cho mã trạng thái khi thực sự có phản hồi HTTP. Một trạng thái bị thiếu nên tiếp tục bị thiếu trong bản ghi chẩn đoán của bạn.
| Quan sát | Ý nghĩa | Bằng chứng tiếp theo |
|---|---|---|
| ERR_CONNECTION_RESET | Một kết nối đã bị đặt lại | Tài nguyên và giai đoạn bị lỗi |
| Mã lỗi HTTP | Đã nhận được một phản hồi HTTP | Trạng thái, nội dung phản hồi, hop phản hồi |
| Đã tải shell nhưng thiếu nội dung | Tài liệu chính tồn tại nhưng dữ liệu có thể vắng mặt | Kết quả yêu cầu script và dữ liệu |
| Kết quả bộ chọn rỗng | Kết quả DOM được kỳ vọng đã vắng mặt | Độ chính xác nhận dạng đã render và bộ chọn |
Một trạng thái HTTP thành công không khẳng định rằng tất cả tài nguyên phụ thuộc đã được tải. Trang chính có thể trả về thành công trong khi một endpoint dữ liệu bị reset. Ngược lại, một điều hướng có thể thất bại trước khi ứng dụng nhận được bất kỳ phản hồi HTTP nào. Hãy giữ trạng thái tài liệu, danh sách tài nguyên bị lỗi và mức độ sẵn sàng nội dung như những tín hiệu riêng biệt.
Tránh coi một kết quả trích xuất rỗng là một chẩn đoán mạng. Một bộ chọn không khớp có thể xuất phát từ cấu trúc trang thay đổi, render chưa hoàn tất, màn hình lỗi, hoặc một trang thực sự không có bản ghi phù hợp. Nhật ký mạng và trạng thái trang đã render quyết định cách diễn giải nào được hỗ trợ.
ERR_CONNECTION_RESET trong Tự động hóa Trình duyệt
Tự động hóa trình duyệt cần các quy tắc chấp nhận bản ghi rõ ràng. Một lỗi điều hướng nên tạo một sự kiện bản ghi thất bại với chuỗi lỗi gốc. Không bắt ngoại lệ rồi lập tức trích xuất bất kỳ DOM nào sẵn có mà không kiểm tra tài liệu nào đang hiện diện. Trang vẫn có thể hiển thị một lần điều hướng trước đó hoặc một trang lỗi của trình duyệt.
Với một điều hướng đã tới được tài liệu, hãy kiểm tra URL cuối cùng và định danh nội dung được kỳ vọng. Một bộ thu thập sản phẩm có thể yêu cầu đúng định danh sản phẩm và tiêu đề trang trước khi chấp nhận giá trị. Một bộ thu thập tri thức có thể yêu cầu một phần thân bài viết có thể nhận diện được. Những quy tắc này là các quyết định của ứng dụng, vì vậy hãy định nghĩa chúng cho mục tiêu thay vì dựa vào một tín hiệu chung chung “trang đã tải”.
Hiện tại Khả năng của Scrapeless Agent Browser bao gồm các phiên trình duyệt được quản lý cho các trang web động. Một phiên trên đám mây thay đổi môi trường thực thi trình duyệt và tuyến đi ra, nên nó có thể hữu ích để so sánh lỗi cục bộ với một phiên từ xa. Việc so sánh đó nên giữ nguyên mục tiêu và yêu cầu bản ghi. Một trang từ xa thành công không chứng minh được lý do tại sao yêu cầu cục bộ bị reset.
Khi máy khách cục bộ kết nối tới trình duyệt từ xa, hãy phân biệt kết nối điều khiển với điều hướng mục tiêu của trình duyệt. Mất phiên điều khiển và nhận lỗi mạng ở mục tiêu là hai sự kiện khác nhau. Ghi lại thao tác nào đã báo cáo lỗi. Không có sự phân biệt đó, một nhóm có thể tốn thời gian gỡ lỗi một đích mà trình duyệt chưa từng cố gắng tải.
Giữ Bằng chứng Trình duyệt Hữu ích và Dễ Chia sẻ
Một báo cáo reset tốt chứa tài nguyên bị lỗi, giai đoạn yêu cầu đã quan sát, và các kiểm tra phạm vi đã hoàn tất. Bao gồm phiên bản trình duyệt, tuyến hiệu dụng, và trạng thái trang nhìn thấy cuối cùng khi những chi tiết đó quan trọng. Giữ báo cáo đủ súc tích để người vận hành nhận có thể ghép nó với nhật ký của họ.
Xuất mạng có thể bao gồm cookie, giá trị ủy quyền và tham số yêu cầu riêng tư. Hãy đỏ tên (redact) những trường đó trước khi chia sẻ. Nếu câu hỏi chỉ liên quan tới một trang công khai, thường không có lý do gì để xuất nội dung của một phiên đã xác thực không liên quan. Thu thập vết (trace) nhỏ nhất có thể trả lời câu hỏi về kết nối.
Sản phẩm Scrapeless Agent Browser hữu ích khi quy trình làm việc của bạn cần thực thi trình duyệt được quản lý. Phần proxy connectivity checks mô tả một cách liên quan để xác định liệu một tầng định tuyến có thể sử dụng được hay không. Xem lại Scrapeless plan options so với nhu cầu phiên thực tế của bạn sau khi xác định liệu khối lượng công việc có cần render bằng trình duyệt hay không.
Một thiết kế giám sát hữu ích ghi nhận lỗi mạng của trình duyệt tách biệt với phân bố trạng thái HTTP và chất lượng trích xuất. Việc đó cho phép sự gia tăng ERR_CONNECTION_RESET nổi bật so với bộ chọn bị thiếu hoặc nội dung rỗng. Nó cũng cung cấp cho bạn một hạng mục ổn định ngay cả khi thông điệp hiển thị của trình duyệt thay đổi cách diễn đạt.
Giải Quyết Yêu Cầu Bị Lỗi, Sau Đó Kiểm Tra Lại Trang
ERR_CONNECTION_RESET nên dẫn đến một chẩn đoán ở mức yêu cầu. Xác định tài nguyên bị lỗi, so sánh hồ sơ và tuyến bị ảnh hưởng, và dùng nhật ký để gán nguyên nhân gián đoạn khi có thể. Giữ một phép so sánh thành công tách biệt với một nguyên nhân gốc đã được khẳng định.
Sau khi sửa ranh giới đã được xác định, hãy xác nhận biểu diễn mục tiêu và nội dung được kỳ vọng của nó. Kết thúc thực tế là một bản ghi hoàn chỉnh, sử dụng được với tuyến đã được ghi lại, chứ không chỉ là sự biến mất của một thông báo trình duyệt. Tiêu chuẩn đó bảo vệ dữ liệu hạ nguồn khỏi các tài liệu tải dở hoặc không liên quan.
Xây Dựng Quy Trình Dữ Liệu Web Có Khả Năng Quan Sát Tốt Hơn
Sử dụng một phiên Agent Browser được quản lý khi bộ thu thập của bạn cần render bằng trình duyệt, và xác thực định danh tài liệu trước khi chấp nhận nội dung đã trích xuất.
Đăng ký hôm nay và nhận $5 tín dụng miễn phí — không cần thẻ tín dụng.
Nhận $5 Tín Dụng Của Bạn →FAQ
H: ERR_CONNECTION_RESET có luôn nghĩa là máy chủ đang ngoại tuyến không?
ERR_CONNECTION_RESET không khẳng định rằng máy chủ đang ngoại tuyến. Một reset có thể được quan sát ở biên máy khách, trung gian và máy chủ. So sánh yêu cầu bị ảnh hưởng trên các tuyến đã được phê duyệt và đối chiếu nhật ký trước khi gán nguyên nhân.
H: Bạn có nên xóa toàn bộ dữ liệu trình duyệt để sửa lỗi reset không?
Xóa toàn bộ dữ liệu trình duyệt không phải là bước chẩn đoán đầu tiên hữu ích cho một lỗi kết nối reset. Hãy so sánh một hồ sơ sạch trước và giữ hồ sơ bị lỗi như bằng chứng. Chỉ xóa trạng thái cụ thể của trang web khi cuộc điều tra liên kết được trạng thái đó với lỗi.
Q: Một trang có thể hiển thị nội dung bất chấp việc reset không?
Một trang có thể hiển thị nội dung khi một tài nguyên bị reset trong khi các tài nguyên khác đang tải. Xác định xem tài liệu chính, một script hay một yêu cầu dữ liệu bị lỗi. Trang hiển thị được có thể vẫn chưa hoàn chỉnh ngay cả khi tài liệu chính đã trả về thành công.
Q: Trình duyệt đám mây có thể xác định nguyên nhân reset cục bộ không?
Trình duyệt đám mây cung cấp một môi trường so sánh, chứ không phải tự động quy kết nguyên nhân reset cục bộ. Một lần điều hướng từ xa thành công sẽ thu hẹp phạm vi điều tra vào các điều kiện khác nhau giữa hai tuyến. Nhật ký và các phép so sánh có kiểm soát vẫn cần thiết để xác định nguyên nhân cục bộ.