Коротко по делу
Браузер и git могут идти разными маршрутами
Браузер обычно обращается к GitHub по HTTPS, а репозиторий можно клонировать по HTTPS или SSH. Даже когда оба варианта используют интернет через один компьютер, они могут иметь разные proxy-настройки и правила split tunneling. Поэтому факт открытия сайта не доказывает, что процесс git или ssh направляется через тот же VPN-интерфейс.
Скопируйте точный remote URL и определите схему. Для HTTPS диагностируйте DNS, TLS и proxy git. Для SSH диагностируйте разрешение имени, маршрут и доступность используемого SSH-порта. Не смешивайте эти ветки до первого результата.
Проверьте proxy, DNS и адресное семейство
Git может наследовать переменные HTTP_PROXY и HTTPS_PROXY или иметь собственные значения в конфигурации. Старый локальный proxy после включения VPN способен отправлять git в несуществующий путь, пока браузер работает напрямую. Аналогично SSH может использовать Host, ProxyCommand или другой alias из пользовательского config.
Отдельно сравните IPv4 и IPv6. Если DNS возвращает оба семейства, а VPN корректно маршрутизирует только одно, соединение может долго ожидать нерабочий адрес. Это особенно заметно как «вечный clone» без явной ошибки. Исправлять лучше маршрут или настройки клиента, а не отключать защиту TLS.
Минимальный порядок диагностики
Сначала повторите операцию с подробным выводом git или ssh и зафиксируйте место зависания. Затем проверьте, резолвится ли hostname одинаково при VPN on и off, какой remote используется и есть ли proxy-настройки. После этого сравните поведение в другой сети или с другим протоколом clone.
Если HTTPS работает, а SSH нет, не меняйте репозиторий и токены до проверки сетевого пути SSH. Если оба clone-варианта не работают, но сайт открывается, наиболее вероятна разница между браузером и системным маршрутом процесса. Такая последовательность дает воспроизводимую причину вместо случайного перебора параметров.
Продолжить чтение