Ofisdəki Wi-Fi-da işləyir, telefon hotspotunda uğursuz olur, hər iki halda VPN qoşulub. Git 403 qaytarır və xəta üç sətirdən ibarətdir. Cazibə hotspotu səbəb saymaq və nə isə dəyişənə qədər şəbəkə parametrlərini dəyişməkdir. HTTP 403 o deməkdir ki, server sorğunu başa düşüb və ondan imtina edib, ona görə faydalı sual hansı serverdir və faydalı növbəti addım hər dəfə bir şeyi dəyişən müqayisədir.

Şəbəkədən əvvəl statusu oxuyun

403 nə axtarış uğursuzluğu, nə TCP fasiləsi, nə də tamamlanmamış TLS əl sıxışmasıdır. Bu, sorğunuzu təhlil edən bir şeyin verdiyi qərardır.

Bu qərarı nəyin verdiyini bilənə qədər sınadığınız hər şəbəkə dəyişikliyi inandırıcı hekayə ilə bəzənmiş təxmindir.

403 ilə kim cavab verə bilər?

Repo tətbiqi yalnız bir namizəddir. Proxy, şlüz və ya filtrləmə xidməti onun qarşısında oturub birinci cavab verə bilər və müştəri hər iki halda eyni statusu görür. Statusu, aid başlıqları və təmizlənmiş xəta gövdəsini saxlayın, sonra onları icazəli xidmətin qeydləri ilə əlaqələndirin. Uzaq URL və faktiki çatılan son nöqtə DNS və ya proxy konfiqurasiyası səbəbindən də fərqlənə bilər, ona görə konfiqurasiya edilmiş ünvanı və sorğunu göndərən prosesi yoxlayın.

İmtina repoya çatmayıbsa, onun qeydləri səssiz olacaq və bu səssizlik sübutdur.

Hər dəfə bir dəyişəni müqayisə edin

Hotspot müqayisəsi problemi daraltdığı üçün faydalıdır, səbəbi sübut etdiyi üçün deyil. İki şəbəkə eyni anda ünvanlama, IP ailəsi, proxy, TLS danışığı və çıxış siyasəti baxımından fərqlənə bilər.

Hər cəhddə bir şeyi dəyişin və qalanını qeyd edin. Aşağıdakı cədvəl bunu edərkən qeyddə saxladığım minimumdur:

Keep constantRecord when it changes
Repository, operation and credentialsResolved address and IP family
Git process and configurationProxy use and the responding component
Intended VPN profileActual route and exit seen by the service

İşləyən və uğursuz iş arasında fərqlənən tək sətir növbəti saatın hara getdiyidir.

Müvəqqəti həll sübutdur, izah deyil

Başqa ünvan ailəsini məcbur etmək təyinatı, marşrutu və ya seçilən ara komponenti dəyişə bilər, yəni IPv6-nın repo ilə uyğunsuz olduğunu sübut etmədən nəticəni dəyişə bilər. Danışılan fərqli TLS versiyası da eyni kateqoriyada bir müşahidədir. Heç biri sertifikat yoxlamalarını söndürməyi və ya bağlantını zəiflətməyi əsaslandırmır. İlk işləyən dəyişiklikdə dayanmaq əvəzinə imtina edən komponentin siyasətini və qeydlərini faktiki qərara qədər izləyin.

İzah edə bilmədiyiniz müvəqqəti həll başqa yerdə yenidən uğursuz olacaq.

Düzəldiləcək hesabat yazın

Cavab verən komponentin sahibinə eyni əməliyyatı, iki yolu və imtina edən komponenti verin. Paylaşmazdan əvvəl avtorizasiya başlıqlarını, daxil edilmiş etimad məlumatlarını və şəxsi repo detallarını silin.

Faydalı hesabat qısa və təkrarlana bilən olur və simptomu deyil, təbəqəni adlandırır.

Sıra ilə etdiyim yoxlama

Uzaq URL-i və həll edilmiş son nöqtəni təsdiqləyin, sonra uğursuz işdən statusu və başlıqları çıxarın. Eyni əməliyyatı ikinci şəbəkədə təkrarlayın və iki qeydi müqayisə edin.

Sonra bu fərqi cavab verən komponentə aparın:

  • Müştəridə və şəbəkədə proxy konfiqurasiyası.
  • Reponun qarşısında çıxış siyasəti və ya filtrləmə.
  • Token və ya hesab əhatəsi, o cümlədən bitmə və SSO şərtləri.
  • Tokenin təmsil etdiyi şəxsiyyət üçün repo icazəsi.

Status semantikası RFC 9110-da verilib və hesabatı yazarkən ondan sitat gətirməyə dəyər.

Əlaqəli məqalələr