Hai câu "kết nối có thể được thực hiện" và "Tôi có thể tiếp tục với những gì tôi định làm" khác xa với nhau và một bài kiểm tra kết nối TCP đơn giản như Test-NetConnection hoàn toàn không kiểm tra điều tương tự như thực tế bản sao git.
Khả năng mở kết nối TCP tới một cổng không có nghĩa là quyền truy cập vào dịch vụ đang lắng nghe trên cổng đó. Có nhiều giai đoạn sau khi kết nối ban đầu có thể không thành công, chẳng hạn như đàm phán TLS, xác thực, ủy quyền hoặc trao đổi giao thức cấp ứng dụng.
Ngoài ra, các hạn chế tường lửa không phải là lý do duy nhất có thể khiến kết nối TCP không thành công và lỗi kết nối TCP không phải là tác động duy nhất có thể có của hạn chế tường lửa. Vì vậy, tuyên bố của bạn:
Nếu tôi không thể truy cập trang web trên một cổng cụ thể, thì điều đó có nghĩa là tôi cần sửa đổi tường lửa trước khi tiếp tục.
và
Mặt khác, nếu tôi có thể truy cập trang web, thì tôi sẽ có thể tiến hành những gì tôi định làm.
cả hai đều sai.
Điều này có nghĩa là, thay vì tự hỏi tại sao bạn Test-NetConnection kiểm tra không phát hiện ra vấn đề mà sau này khiến quyền truy cập GitHub của bạn không thành công, thì bạn nên phân tích vấn đề đó thực sự là gì rồi đánh giá xem việc phát hiện trước vấn đề cụ thể đó có mang lại lợi ích gì không. Nếu câu trả lời là có, thì bạn có thể nghĩ ra một bài kiểm tra để làm điều đó.
Trong thực tế, thường thì cách hành động hiệu quả nhất là chỉ thử hoạt động dự định mà không có bất kỳ thử nghiệm nào trước đó và xử lý mọi lỗi khi chúng xảy ra. Việc kiểm tra trước các vấn đề hầu như chỉ có ý nghĩa nếu chúng có thể được khắc phục tự động hoặc nếu việc thử và vận hành thực tế không thành công sẽ gây ra rủi ro hoặc chi phí đáng kể.
Cụ thể, các hoạt động của GitHub không thành công khá nhẹ nhàng và có dấu hiệu rõ ràng hợp lý về nguyên nhân gây ra lỗi, vì vậy tôi không thấy lợi ích trực tiếp nào trong việc kiểm tra kết nối trước thay vì chỉ thử trực tiếp thao tác dự kiến.
