Если GitHub в Китае не работает, сначала назовите точную операцию: загрузка страницы репозитория, разрешение имени хоста, вход, прохождение SSO, запрос к API, клонирование, получение изменений или отправка по HTTPS либо SSH. У этих путей разные хосты, протоколы, учётные данные и правила организации. Открывшаяся веб-страница не доказывает, что push сработает, а один неудачный clone не означает, что GitHub недоступен везде.

Ключевые выводы:

Сохраните коммиты, патчи и неотслеживаемые файлы до проверки учётных данных, remote и прокси.

Запишите команду, протокол, хост, сеть, время и ошибку, не раскрывая токены и данные репозитория.

Проверяйте веб, API, Git по HTTPS и Git по SSH отдельно; один endpoint не описывает всю платформу.

Не отключайте TLS, проверку SSH host key, SSO и правила организации ради диагностики.

Это рабочий чек-лист, а не обещание доступности сервиса или маршрута в любом месте. Публичные рекомендации для поездок отмечают ограничения доступа к интернету в Китае, но условия меняются в зависимости от сервиса, провайдера, места и времени.［1］ Для общего первого прохода используйте чек-лист интернета в материковом Китае; здесь рассматривается только рабочий процесс GitHub.

Что именно не работает в GitHub в Китае?

Составьте небольшую матрицу отказа

Используйте репозиторий, к которому у вас есть право доступа, и недеструктивную операцию. Не проверяйте связь принудительным push, удалением credentials или множественными попытками входа.

Поверхность	Безопасное наблюдение	О чём говорит различие
Публичная страница	Загружается полностью, частично или истекает время?	Браузер, DNS, TLS, CDN или маршрут
Веб после входа	Открывается ли нужная организация?	Провайдер входа, MFA, SSO, сессия или политика
Git по HTTPS	Доходит ли `fetch` до remote, а затем отклоняет доступ?	Транспорт работает; далее проверяются права
Git по SSH	Обрывается ли соединение до проверки репозитория?	Порт, прокси, host key или SSH-ключ
API	Возвращает ли документированный запрос HTTP-ответ?	Хост API, scope токена, лимит или политика
Другой репозиторий	Отличается ли разрешённый тестовый репозиторий?	Размер, LFS, права, hooks или правила организации

Официальная инструкция GitHub предлагает проверять соединение, использовать актуальные сведения об IP-адресах GitHub только при необходимости и привлекать сетевого администратора, если участвуют firewall, proxy или корпоративная сеть.［2］ Сторонние зеркала и скопированные учётные данные не являются безопасным диагностическим сокращением.

1. Сохраните локальную работу и минимальное воспроизведение

До изменения конфигурации убедитесь, что сохранённая в commit работа доступна локально, а незаменимые неотслеживаемые файлы скопированы в разрешённое защищённое место. Запишите remote без секретов, точную операцию (clone, fetch, pull, push, API или браузер), используемый протокол, примерное время и полный текст ошибки. Отдельно сохраните версию Git и отметьте, участвуют ли Git LFS, submodules, credential helper либо корпоративный SSO: каждый из этих компонентов может относиться к другой границе проверки.

Для чтения можно применить git ls-remote только к репозиторию, к которому у вас есть доступ. Не делайте частых повторов: они скрывают временную картину, могут активировать ограничения частоты или проверки личности и мешают корректно сравнивать две сети. Перед передачей лога удалите чувствительные имена, но сохраните саму операцию, протокол, время и точную ошибку, иначе минимальное воспроизведение потеряет диагностическую ценность.

2. Разделите браузер, DNS, TLS и состояние сервиса

Сравните публичную страницу GitHub, страницу входа, страницу нужного репозитория и официальный статус сервиса. Расширение браузера, кэшированная сессия, управляемый сертификат, DNS resolver или captive portal могут влиять на браузер иначе, чем на Git в командной строке, и возможна обратная ситуация. Приватное окно используйте только когда это разрешено политикой организации; не очищайте все данные браузера до сохранения полезной ошибки и сведений о сессии.

Читайте ошибку буквально и не сводите разные ответы к общей формулировке «GitHub недоступен». Сбой разрешения имени, TCP timeout, ошибка TLS-сертификата, ответ HTTP-прокси, коды 403, 404, 429 и 5xx относятся к разным слоям и требуют разных следующих проверок. Нельзя обходить предупреждение сертификата или устанавливать непроверенный корневой сертификат только ради загрузки страницы.

3. Как проверить HTTPS Git, не ослабляя TLS?

Убедитесь, что remote имеет ожидаемый вид https://github.com/OWNER/REPOSITORY.git, и сопоставьте его с официальной процедурой клонирования.［3］ Если соединение дошло до GitHub, но вход отклонён, проверьте поддерживаемый способ credentials, scope и срок токена, SSO-авторизацию и права репозитория. Парольную аутентификацию для Git-операций нельзя подставлять вместо поддерживаемого процесса credentials.

Раздельно изучите proxy на уровне репозитория, пользователя и системы, а также связанные переменные окружения, не печатая секреты. Устаревший proxy может ломать Git при работающем браузере, поскольку эти клиенты необязательно используют одну конфигурацию. Меняйте только один уровень за раз и сохраняйте исходное значение для возврата. Не задавайте http.sslVerify=false, не подавляйте проверку сертификата другим способом и не сохраняйте credential в URL remote.

4. Рассматривайте SSH как отдельный транспорт

Проверьте, что remote ведёт на ожидаемый хост GitHub, SSH предлагает правильный ключ, а этот ключ привязан к нужному аккаунту или организации. Проверка host key — граница безопасности: сравните наблюдаемый fingerprint с опубликованными GitHub значениями и остановитесь при расхождении. Не удаляйте весь known_hosts, не принимайте неизвестный ключ вслепую и не включайте permissive-режим проверки.

Порт 22 может вести себя иначе, чем HTTPS в конкретной сети. GitHub документирует SSH через HTTPS-порт для сетей, блокирующих обычный SSH; следуйте только этой официальной инструкции и до использования проверьте host key альтернативного хоста.［4］ Это меняет транспортный путь, но не добавляет права, не завершает SSO и не отменяет branch protection, требования подписи или правила организации.

5. Что мешает: личность, scope API, SSO или правила организации?

Отделяйте authentication от authorization. Действующая сессия или токен могут не иметь доступа; организация может требовать SAML SSO, IP allowlist, одобренные OAuth-приложения, согласование fine-grained token, managed users или SSH-сертификат. Код 404 для приватного репозитория может намеренно скрывать его наличие.

Для API запишите хост, HTTP-статус, rate-limit headers, тип токена и требуемый scope, не записывая сам токен. Выполните самый маленький документированный запрос чтения и не расширяйте его права ради диагностики. Политику должен подтвердить владелец организации или сетевой администратор; её нельзя обходить изменением маршрута. Результат личного репозитория также не доказывает, что корпоративная организация должна вести себя так же.

6. Проверьте локальный прокси и один контролируемый маршрут

Составьте перечень proxy браузера и операционной системы, настроек Git, SSH ProxyCommand или ProxyJump, IDE, контейнера и переменных окружения. Частая причина — конфликт между слоями: браузер идёт одним маршрутом, а Git, расширение IDE или контейнер другим. Не очищайте конфигурацию целиком; удаляйте или меняйте только ту устаревшую запись, назначение которой вы можете объяснить.

Если закон и политика организации разрешают, повторите ту же неразрушительную операцию чтения через один контролируемый альтернативный маршрут. VPN может изменить сетевой путь, но не устраняет инцидент GitHub, не выдаёт права репозитория, не завершает SSO, не одобряет token и не отменяет корпоративные правила. Сохраняйте команду, аккаунт, репозиторий и временное окно одинаковыми, иначе сравнение не изолирует маршрут. Если такое сравнение разрешено, альтернативный маршрут для той же проверки git ls-remote может дать AethoVPN.

7. Восстановите работу безопасно и запишите границу

Примените самое узкое подтверждённое исправление: исправьте разрешённый proxy, обновите одобренный credential, авторизуйте SSO, попросите администратора изменить политику, используйте документированный альтернативный SSH-порт или дождитесь окончания подтверждённого инцидента. Затем повторите именно исходную операцию и проверьте состояние репозитория. Для push подтвердите ожидаемый remote commit через разрешённый интерфейс: само отсутствие сообщения об ошибке ещё не доказывает успешную отправку.

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

Итоги

Определите точную поверхность GitHub, протокол и разрешённую операцию до начала диагностики.
Сохраните локальную работу и соберите минимальное обезличенное воспроизведение ошибки.
Разделяйте веб, API, HTTPS, SSH, вход и политику организации.
Не отключайте TLS или SSH-проверку и не обходите правила работодателя.
Проверяйте восстановление на уровне репозитория и фиксируйте границы.

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

GitHub полностью заблокирован в Китае?

Универсальный ответ «да» или «нет» не описывает меняющийся и зависящий от маршрута результат. Проверьте конкретную разрешённую web-, Git- или API-операцию в текущей сети и запишите дату, место и endpoint. Успех одной поверхности нельзя переносить на остальные.

Почему github.com открывается, а git clone не работает?

У браузера и Git могут различаться протокол, proxy, credentials, используемые hosts и правила организации. Поэтому загрузка github.com не подтверждает работу clone: диагностируйте HTTPS или SSH независимо от веб-страницы и сохраняйте точную ошибку каждого транспорта.

Стоит ли отключить SSL verification?

Нет. Ошибка TLS может означать перехват, неверные часы, captive portal, managed certificate или опасный маршрут. Исправьте доверие или путь.

Можно ли переключиться с SSH на HTTPS?

Да, если репозиторий и организация это допускают. Используйте официальный формат remote и одобренный способ credentials; права от смены транспорта не появятся.

Что делать, если SSH-порт 22 не отвечает?

Если это разрешено, следуйте официальной процедуре GitHub для SSH через HTTPS-порт, проверьте fingerprint и оставьте строгую проверку host key.

Почему личный репозиторий работает, а корпоративный нет?

Организация может требовать SSO, одобренные токены, IP-правила, managed identity или другие права. Уточните политику у администратора.

Гарантирует ли VPN работу GitHub push?

Нет. Маршрут — лишь один слой; результат также определяют сервис, credentials, SSO, права, hooks, branch protection и политика.

Отказ от ответственности: материал содержит общую операционную информацию, а не юридическую консультацию, рекомендации по безопасности или правилам работодателя. Соблюдайте закон, корпоративные требования и актуальную документацию GitHub.

Источники

UK Government, China travel advice, internet access and security: https://www.gov.uk/foreign-travel-advice/china/safety-and-security
GitHub Docs, Troubleshooting connectivity problems: https://docs.github.com/en/get-started/using-github/troubleshooting-connectivity-problems
GitHub Docs, Cloning a repository: https://docs.github.com/en/repositories/creating-and-managing-repositories/cloning-a-repository
GitHub Docs, Using SSH over the HTTPS port: https://docs.github.com/en/authentication/troubleshooting-ssh/using-ssh-over-the-https-port

Sources checked 12 сентября 2026 г.

Рекомендуемые статьи:

GitHub в Китае: чек-лист доступа для разработчиков