Работает ли GitHub Actions в Китае? Единого сетевого пути здесь нет: раннер GitHub выполняет задания в инфраструктуре GitHub, а собственный раннер в материковом Китае использует исходящий маршрут своей машины. Сначала определите тип раннера и первый сбойный шаг; очередь, тайм-аут checkout, отсутствующий секрет, ошибка артефакта и сбой сторонней службы требуют разных действий.

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

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

Результат раннера GitHub не измеряет локальную сеть разработчика в Китае; этот маршрут использует только расположенный там собственный раннер.

Собственный раннер сам устанавливает исходящие соединения и требует одобренного доступа к официальным адресам GitHub.

Изменение маршрута не исправляет метки, разрешения, секреты, политики организации, оплату, синтаксис рабочего процесса или стороннюю службу.

Для общих проверок браузера и маршрута начните с диагностики сервисов в материковом Китае. Доступ с рабочей станции к сайту GitHub, API, Git по HTTPS, SSH, SSO и репозиториям разобран в отдельном контрольном списке GitHub. Руководство по VPN для Китая задает общую сетевую и правовую границу; здесь рассматривается только выполнение GitHub Actions.

На каком этапе работы раннера возникает ошибка, если GitHub Actions в Китае не работают?

Постройте временную линию исполнения

Рабочий процесс должен быть запущен событием, принят, поставлен в очередь, назначен подходящему раннеру и завершить все сетевые шаги. Запишите URL запуска и задания, событие, commit, тип и метки раннера, первый сбойный шаг, время и очищенный от секретов текст ошибки.

Этап	Что сохранить	Типичная несетевая причина
Запуск	Событие, ветка, фильтры и версия рабочего процесса	Фильтр путей, отключенный процесс или синтаксис
Очередь	Запрошенные метки, группа и состояние ожидания	Нет подходящего раннера, ограничение параллелизма или тарифа
Сеанс раннера	Образ GitHub или идентификатор собственного раннера	Служба не в сети, обновление или ошибка назначения
Checkout и службы	Первый узел и операция с ошибкой	Область токена, разрешение или состояние репозитория
Команда процесса	Код выхода и ограниченный журнал	Ошибка теста, отсутствующий секрет или сбой сторонней службы

Не помещайте секреты, токены OIDC, названия закрытых репозиториев, регистрационные токены раннера, внутренние адреса или полный дамп окружения в публичные задачи.

1. Определите, где фактически выполняется задание

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

Собственный раннер работает на инфраструктуре, которую развертывает и обслуживает владелец.［2］ Запишите физическое расположение или облачный регион, операционную систему, версию раннера, учетную запись службы, источник proxy, метки, группу и признак одноразового запуска. Если узел расположен в материковом Китае, важен его собственный одобренный исходящий маршрут.

Не определяйте расположение по человеку, нажавшему «Run workflow». Checkout и команды выполняет узел исполнения, а не браузер оператора.

2. Отделите запуск и очередь от сетевого соединения

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

Для задания в очереди сравните запрошенные метки и группу с зарегистрированными раннерами. Проверьте ограничение параллелизма, одобрение окружения, лимиты тарифа или оплаты, политику организации и административный запрет Actions либо конкретного action. Ожидание метки, которой не соответствует ни один раннер, не является сетевой ошибкой в Китае.

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

3. Проверьте собственный раннер и исходящие соединения

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

GitHub сообщает, что собственный раннер через исходящее соединение получает задания и загружает обновления; для обычной работы входящие соединения со стороны GitHub не нужны.［2］ Узел должен разрешать DNS и HTTPS к документированным адресам через одобренный межсетевой экран либо proxy. Некоторые необходимые домены указывают на CNAME, поэтому правила экрана могут потребовать рекурсивной обработки.［2］

Согласуйте с владельцем сети текущий официальный список доменов. Не отключайте TLS, не принимайте сертификат с несовпадающим именем, не открывайте входящий порт раннера и не обходите корпоративные средства контроля.

4. Разделите checkout, actions, артефакты, кэш и пакеты

После запуска раннера найдите первый шаг, зависящий от сети. Checkout репозитория может обращаться к GitHub API, архиву, Git по HTTPS, LFS или подмодулям. Загрузка actions, выпусков, образов контейнеров, пакетов и кэша, а также службы артефактов могут использовать другие узлы. Успешный checkout не доказывает, что отправка артефакта или загрузка образа контейнера тоже пройдут.

Запишите название action и неизменяемую ревизию, операцию, категорию узла, статус, тайм-аут и объем переданных байтов. Сторонние actions из Marketplace и API, вызванные самим рабочим процессом, отделяйте от служб GitHub. Сбой внешней службы нельзя называть недоступностью GitHub Actions.

Когда ошибку выдает система доставки пакетов, используйте отдельные инструкции для Docker Hub, npm или PyPI.

5. Проверьте токены, разрешения, секреты, OIDC и политики

Ответ HTTP показывает, что запрос достиг службы, но проверка личности или права доступа еще может завершиться отказом. Проверьте объявленные для задания permissions, политику Actions репозитория или организации, ограничения для fork, одобрения окружения, доступность секретов, защищенные ветки и передачу секретов в повторно используемый процесс. Не печатайте утверждения токена и значения секретов.

OIDC включает запрос токена у GitHub и обмен удостоверением с облачным провайдером. Отделяйте ошибку запроса токена GitHub от проверки издателя, аудитории, субъекта, роли или политики у провайдера. Изменение маршрута не исправляет неверную политику доверия.

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

6. Сравните минимальное задание в контролируемых условиях

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

Если это допускают применимое право и политика, AethoVPN может дать контролируемый альтернативный маршрут для собственного self-hosted runner: установите на эту машину клиент для Linux (пакет .deb для Debian/Ubuntu) или Windows, подключитесь к одной локации из списка и перезапустите ту же минимальную задачу, чтобы менялся только сетевой путь. Он не исправит инцидент на стороне GitHub, отсутствующие метки, политику Actions, оплату, секреты, логику workflow или сторонний адрес, и его нельзя ставить на управляемую инфраструктуру без согласия владельца. Для личной тестовой машины начните 3-дневный пробный период AethoVPN, прежде чем менять настройки runner.

Полезный вывод должен быть узким: например, задание в инфраструктуре GitHub проходит, а собственный раннер в Китае не достигает адреса службы артефактов. Это не постоянное заявление обо всех рабочих процессах Actions в стране.

7. Подтвердите восстановление от запуска до итогового артефакта

Примените только подтвержденное исправление: восстановите одобренную службу раннера, исправьте точные метки, обновите разрешенный proxy или список доступа, скорректируйте разрешения, зафиксируйте ревизию action, исправьте рабочий процесс или дождитесь устранения сбоя, официально подтвержденного GitHub. После сохранения исходного запуска повторите тот же commit и процесс.

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

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

Итоги

Определите расположение раннера и разделите запуск, очередь, назначение и исполнение.
Отдельно нанесите checkout, actions, артефакты, кэш, пакеты, OIDC и сторонние вызовы.
Для собственного раннера проверяйте разрешенный исходящий HTTPS, не открывая входящий доступ.
Сохраняйте токены, TLS, политику организации и доверие к раннеру.
Повторите тот же commit и проверьте все обязательные задания и артефакты.

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

Раннер GitHub использует мое подключение в Китае?

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

Нужен ли собственному раннеру входящий порт межсетевого экрана?

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

Почему задание остается в очереди и не начинается?

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

Почему checkout работает, а отправка артефакта нет?

Checkout и службы артефактов могут использовать разные адреса, токены и схемы передачи. Отдельно зафиксируйте первый запрос к службе артефактов и его статус.

Может ли VPN исправить отсутствующий секрет Actions?

Нет. Маршрутизация не создает секреты, не выдает разрешения токену, не одобряет окружения и не меняет политику организации.

GitHub Actions и доступ к сайту GitHub — один тест?

Нет. Сайт, транспорт Git, API, раннер GitHub, собственный раннер и зависимости рабочего процесса используют разные пути. Для рабочей станции используйте отдельное руководство по GitHub.

Как доказать работу раннера Actions из Китая?

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

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

Источники

GitHub Docs, GitHub-hosted runners reference: https://docs.github.com/en/actions/reference/runners/github-hosted-runners
GitHub Docs, Self-hosted runners reference: https://docs.github.com/en/actions/reference/runners/self-hosted-runners

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

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

Работает ли GitHub Actions в Китае? Проверка раннера