Настройка прокси в Git: HTTPS, уровни конфига и как убрать прокси

Чтобы пустить Git через прокси, когда remote работает по HTTP или HTTPS, начните с http.proxy, заданного для одной команды. Прежде чем прописать его в git config насовсем, проверьте, по какому протоколу работает remote и нет ли отдельных настроек для конкретного URL или remote. Если сбросить общую настройку, эти отдельные настройки могут остаться в силе.

Адреса в примерах условные. Наш стенд, который можно скачать, использует loopback, выдуманные учётные данные и временный репозиторий. Его десять проверок мы прогнали 12 октября 2026 года на Git 2.50.1 (Apple Git-155), Python 3.14.8 и macOS 15.7.4. Стенд проверяет маршрут и содержимое репозитория; работу провайдера прокси он не замеряет, а HTTPS, SSH и push не тестирует.

Проверьте, по какому протоколу работает remote

В существующем репозитории посмотрите адрес remote локально:

git remote get-url origin

URL вида https:// или http:// означает, что Git работает через HTTP-транспорт. Remote вида git@github.com:OWNER/REPO.git или ssh://git@HOST/REPO.git работает по SSH. На SSH-соединение http.proxy не влияет: для этого транспорта следуйте инструкциям вашей организации по маршрутизации SSH. Если вы только собираетесь сделать git clone, проверьте URL, который будете клонировать. Если в URL встроены учётные данные, не оставляйте их в выводе, которым делитесь. Документация по команде git и SSH.

Сначала проверьте прокси на одной команде: git ls-remote или git clone

Задайте в окружении GIT_PROXY_URL и GIT_REPO_URL. GIT_REPO_URL — HTTP/HTTPS-remote, к которому у вас есть доступ, а GIT_PROXY_URL — URL шлюза из документации прокси, например http://proxy.example:8080:

git -c http.proxy="$GIT_PROXY_URL" \
    -c http.lowSpeedLimit=1 -c http.lowSpeedTime=20 \
    ls-remote "$GIT_REPO_URL"

Такая команда не оставляет в конфигурации постоянной записи о прокси. Параметры минимальной скорости обрывают зависшую передачу, но не ограничивают общее время работы команды. Список refs в ответе подтверждает, что ответил репозиторий, но сам по себе успех не доказывает, каким маршрутом шёл запрос. Чтобы клонировать, замените ls-remote на clone и укажите новый каталог назначения.

HTTPS-remote может работать через HTTP-шлюз: схема в URL прокси описывает соединение с самим шлюзом. Указывайте шлюз https://, только если он поддерживает TLS. HTTP-параметры Git, протоколы прокси в libcurl.

Учётные данные прокси и учётные данные репозитория — разные вещи. Согласно документации Git, если в URL прокси есть имя пользователя, но нет пароля, пароль запрашивается через механизм учётных данных Git. Используйте тот способ аутентификации, который поддерживает шлюз. Не храните настоящие URL с учётными данными в конфигурации, которой пользуются другие, и вычищайте их из диагностического вывода. Учётные данные в Git.

Пропишите прокси в git config только там, где он нужен

Когда временная проверка сработала, выберите одну настройку. В командах ниже — условный шлюз без учётных данных:

Для локальной настройки нужен уже существующий репозиторий; для первого клонирования задайте прокси в самой команде или в пользовательском конфиге для конкретного URL. Сопоставление с URL и обычный приоритет уровней конфигурации — два независимых механизма. Настройка для конкретного remote — ещё один уровень переопределения. Уровни конфигурации Git, параметры прокси для remote.

Что показал стенд маршрутизации

Скрипт стенда создаёт bare-репозиторий, HTTP-сервер origin и пересылающий прокси с аутентификацией. В успешных случаях clone/fetch проверяются ожидаемый коммит и точное содержимое файлов; в случаях с прямым соединением прокси не должен получить ни одного запроса. В файле с результатами сохранены команды, запросы, ошибки и версии.

Все десять случаев соответствовали своим критериям приёмки, включая случай с намеренно отклонённой аутентификацией. Девять операций clone/fetch завершились успешно, и содержимое репозитория в них подтвердилось. Эти наблюдения относятся к локальному окружению Git/libcurl, зафиксированному в результатах.

Скачайте скрипт и README в новый каталог и запустите:

python3 git_proxy_lab.py > local-results.json

Стенду нужен Git с поддержкой GIT_CONFIG_GLOBAL (появилась в Git 2.32) и Python с ThreadingHTTPServer (появился в Python 3.7); сторонние пакеты Python не нужны. Эти требования взяты из документации; сам стенд запускали только на Git 2.50.1 / Python 3.14.8. См. примечания к выпуску Git 2.32 и документацию HTTP-сервера Python. Стенд использует IPv4 loopback, отдельные файлы конфигурации Git и базовое окружение без унаследованных переменных прокси. Временные репозитории после прогона удаляются. Стенд отдаёт репозиторий по dumb HTTP и не проверяет smart HTTP, CONNECT, сертификаты, SOCKS, боевые системы аутентификации и SSH. Советы по сертификатам ниже взяты из документации. Документацию сверяли с исходниками Git 2.56.0; запускался бинарник Apple Git 2.50.1.

Как убрать прокси в Git: найдите действующую настройку

Смотрите вывод только у себя: в значениях конфигурации могут быть учётные данные.

git config --show-origin --show-scope --get-regexp \
  '^(http\..*proxy|remote\..*\.proxy)$'
git config --get-urlmatch http.proxy "$GIT_REPO_URL"

Первая команда находит общие записи, записи для конкретных URL и для конкретных remote. Вторая показывает результат сопоставления по HTTP URL; настройку remote она не учитывает и реальный сетевой маршрут не доказывает. Проверьте также переменные прокси и обхода в окружении того процесса, который на самом деле запускается, — см. руководство по переменным окружения.

Удаляйте только нужный ключ и только на нужном уровне. Для записи с хостом из примера:

git config --global --unset-all 'http.https://github.com/.proxy'

Для remote из примера выполните внутри его репозитория:

git config --local --unset-all remote.origin.proxy

Для общей пользовательской записи — git config --global --unset-all http.proxy. Если такого ключа нет, команда завершится с ненулевым кодом. После удаления в силу может вступить другая, оставшаяся настройка, поэтому посмотрите конфигурацию ещё раз и повторите проверку маршрута. Наш стенд показывает, почему, если очистить только http.proxy, прокси для совпавшего URL может остаться в силе.

Определите, какой слой даёт сбой

Для утверждённого корпоративного CA, используемого при перехвате TLS, в Git есть http.sslCAInfo; для TLS-соединения с HTTPS-прокси — отдельный http.proxySSLCAInfo. Доверенные сертификаты получите у администратора и не отключайте проверку. Это два разных соединения, и HTTP-стенд не проверяет ни одно из них. Schannel в Windows может брать сертификаты из своего хранилища, а не из переданного CA-файла; следуйте политике для своей платформы. Параметры TLS в Git.

Чтобы проверить шлюз без участия Git, используйте базовую проверку одним запросом curl с таймаутами. Успешный запрос curl не говорит о том, какой маршрут выберет Git.

При таймауте сначала найдите этап, на котором всё зависает, и только потом увеличивайте лимиты; см. диагностику таймаутов прокси.

ipvolt продаёт мобильные прокси и резидентные прокси от $0.60/ГБ: посмотрите цены.