Битлента
Ошибки и коды3 мин чтения·

git «fatal: unable to access»: как найти сетевую причину

Ошибка git fatal unable to access при clone, pull и push: как читать хвост сообщения, какие сетевые причины бывают и как проверить их по порядку.

Сообщение-обёртка

Строка «fatal: unable to access 'адрес': …» сама по себе ничего не объясняет. Это общий заголовок, за которым git указывает, чем закончилась попытка сетевого обращения. Настоящая причина записана после двоеточия: «Could not resolve host», «Failed to connect to … port 443», «Connection timed out», «SSL certificate problem», «The requested URL returned error: 403».

Поэтому первое действие: скопируйте строку целиком и разберите её хвост. У каждого варианта свой путь диагностики, и путать их значит терять время.

Расшифровка типичных хвостов

«Could not resolve host» означает, что имя сервера не превратилось в адрес: проблема в DNS, в написании адреса или в выключенной сети. «Failed to connect» и «Connection refused» говорят, что до сервера дошли, но порт не принимает соединение, либо путь закрыт файрволом. «Connection timed out» значит, что ответа не было вообще: пакеты теряются на маршруте или отбрасываются.

«SSL certificate problem» относится к проверке сертификата, а «Recv failure: Connection was reset» показывает, что соединение сбросили посреди разговора, чаще всего из-за промежуточный сервер, антивируса или нестабильной сети. «Returned error 403 или 401» уже не про сеть: сервер ответил, но не пустил из-за прав и учётных данных.

Проверка по порядку: git «fatal

Начните с базового: работает ли интернет и открывается ли адрес репозитория в браузере. Если нет, чинить нужно сеть, а не git. Затем проверьте, что адрес написан верно и не содержит опечатки в домене.

Далее посмотрите настройки промежуточного сервера. У git есть собственные параметры промежуточного сервера, а ещё системные переменные окружения. Забытый промежуточный сервер от прежнего места работы очень часто рвёт соединение. Выведите конфигурацию git и убедитесь, что там нет лишних записей.

Попробуйте другую сеть, например мобильную. Если там команда проходит, вина домашнего роутера, DNS провайдера или рабочих ограничений. Для DNS сравните ответ с публичным сервером имён. Для больших репозиториев проверьте стабильность канала: на слабой связи клонирование иногда обрывается на середине.

Если ошибка возникает только при выгрузке больших изменений, а мелкие проходят, подозревайте ограничение размера запроса на промежуточный сервер или нестабильный канал. Разбейте выгрузку на части или увеличьте буфер передачи в настройках git, если ваша сеть его ограничивает.

🛡️ Остались проблемы с соединением?
Можно пользоваться постоянно: российские приложения работают, включать и выключать ничего не нужно. Без карты и регистрации, настройка за пару минут.
Попробовать бесплатно

Что можно исправить самостоятельно

Сбросьте лишние настройки промежуточного сервера, если они не нужны, или задайте правильные. Проверьте системное время и работу антивируса с проверкой HTTPS. Для обрывов на больших репозиториях попробуйте клонирование с ограниченной глубиной истории, чтобы передавать меньше данных за один раз.

Если проблема с HTTPS-адресом неустранима, а у вас настроены ключи, обратитесь к репозиторию по SSH-адресу: он использует другой порт и другой способ проверки. Это не отменяет поиск причины, но позволяет продолжить работу.

При ошибках 401 и 403 проверьте токен доступа и права на репозиторий: пароль от аккаунта многие сервисы для git больше не принимают.

Когда сбой у сервиса

Если у разных людей и в разных сетях та же ошибка при обращении к одному и тому же хостингу, вероятен временный сбой на стороне сервиса. Проверьте его страницу состояния, если она есть, и повторите запрос через некоторое время. Своя сторона остаётся чистой, когда другие репозитории на других серверах работают нормально.

Для наглядности запоминайте порядок: сначала имя (DNS), потом соединение (порт и файрвол), потом защита (сертификат), потом права (401 и 403). Каждый следующий уровень проверять имеет смысл только после того, как предыдущий пройден.

Быстрый набор диагностических команд

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

Параллельно проверьте доступность хоста другим инструментом, например обращением к адресу репозитория через curl: если он отвечает, проблема специфична для git и его настроек, а если тоже падает, ищите причину в сети. Так вы разделите две группы причин за пару минут и не будете менять настройки вслепую.

🛡️ Остались проблемы с соединением?
Можно пользоваться постоянно: российские приложения работают, включать и выключать ничего не нужно. Без карты и регистрации, настройка за пару минут.
Попробовать бесплатно
gitсетьdnsошибки

Часто задаваемые вопросы

Читайте также