Git კვლავ იყენებს პროქსის, რომელიც გეგონათ, რომ წაშალეთ

http.proxy სტრიქონია. მისი 0-ზე დაყენება შეიძლება აიძულოს Git დაუკავშირდეს ჰოსტს, სახელად ფაქტიურად 0, იმის ნაცვლად, რომ პროქსი გამორთოს.

ჯერ იპოვეთ შესაბამისი ჩანაწერები და მათი არეები:

git config --show-origin --show-scope --get-regexp '.*proxy.*'

შეამოწმეთ სისტემური, მომხმარებლის, რეპოზიტორიის, ჩართვისა და URL-სპეციფიკური შეყვანები, ასევე პროცესის რეალური გარემო. შეინახეთ ავტორიზაციის მონაცემების მქონე მნიშვნელობები კონფიდენციალურად. შემდეგ ჰკითხეთ შესაბამის HTTPS დისტანციურ რეპოზიტორიას:

git config --get-urlmatch http.proxy https://git.example/team/project.git

თუ შემოწმებამ აღმოაჩინა ერთი მოძველებული, რეპოზიტორიაში ლოკალური http.proxy ჩანაწერი, გაუშვით ეს განზრახული სამუშაო ასლიდან ამ ჩანაწერის წასაშლელად:

git config --local --unset http.proxy

გამოიყენეთ ის წყარო, რომელიც რეალურად არის მოხსენებული; ეს ლოკალური მაგალითი არ არის ბრძანება მომხმარებლის ან მანქანის ნაგულისხმევების გასუფთავებისთვის. შეამოწმეთ რამდენიმე მნიშვნელობა, სანამ აირჩევთ ოპერაციას, რომელიც ყველას შლის.

წაშლა ავლენს დარჩენილ შეყვანებს. ლოკალურმა unset-მა შეიძლება გამოავლინოს მომხმარებლის ნაგულისხმევი, ხოლო მომხმარებლის ჩანაწერის წაშლამ შეიძლება დატოვოს URL-სპეციფიკური წესი. ნაცვლად ამისა, მკაფიო ცარიელი მნიშვნელობა გამოხატავს განზრახ პირდაპირ გადაფარვას მხარდაჭერილ Git კონფიგურაციაში; ეს სხვა პოლიტიკაა ერთი წყაროს უკან გაწვევისგან.

გამოყავით core.gitProxy და SSH მარშრუტები. თუ მნიშვნელობა დაბრუნდა, შეამოწმეთ ჩართვები, გამშვები პროგრამები, IDE-ები და build ინსტრუმენტები და გაასწორეთ წარმომქმნელი განზრახ არეში. გაიმეორეთ შერჩევის მოთხოვნა და ქსელური ოპერაცია: სწორი შერჩევა არ ადასტურებს კავშირს ან შემდგომ რეპოზიტორიის ავტორიზაციას.