Cele două afirmații „conexiunea se poate face” și „Sunt capabil să procedez cu ceea ce intenționez să fac” sunt departe de a fi echivalente, iar un simplu test de conexiune TCP precum Test-NetConnection nu testează deloc același lucru ca un real clona git.
A putea deschide o conexiune TCP la un port nu implică acces la serviciul care ascultă pe acel port. Există multe etape după conectarea inițială care pot eșua, cum ar fi negocierile TLS, autentificarea, autorizarea sau schimburile de protocol la nivel de aplicație.
De asemenea, restricțiile firewall nu sunt singurul motiv posibil pentru care o conexiune TCP eșuează, iar eșecurile conexiunii TCP nu sunt singurul efect posibil al unei restricții firewall. Deci afirmatiile tale:
Dacă nu pot accesa site-ul pe un anumit port, înseamnă că ar trebui să modific firewall-ul înainte de a continua.
și
În caz contrar, dacă pot ajunge pe site, atunci aș putea continua cu ceea ce intenționez să fac.
sunt amandoua gresite.
Aceasta înseamnă că, în loc să vă întrebați de ce dvs Test-NetConnection testul nu a detectat problema care a cauzat ulterior eșecul accesului dvs. la GitHub, ar trebui să analizați care a fost de fapt acea problemă și apoi să evaluați dacă detectarea acelei probleme în avans ar oferi vreun beneficiu. Dacă răspunsul este da, atunci puteți concepe un test pentru a face exact asta.
În practică, deseori cel mai eficient mod de acțiune este să încercați operațiunea dorită fără teste anterioare și să gestionați orice erori pe măsură ce apar. Verificarea problemelor în avans are sens în mare parte numai dacă acestea pot fi remediate automat sau dacă încercarea și eșuarea operațiunii efective implică un cost sau un risc substanțial.
Mai exact, operațiunile GitHub eșuează destul de grațios și cu o indicație destul de clară a cauzei eșecului, așa că nu văd niciun beneficiu direct în testarea conexiunii mai întâi în loc să încerc doar operațiunea dorită direct.
