Великий китайский файрвол в 2026 году: как устроена интернет-цензура в Китае и что это значит для DevOps

Великий китайский файрвол (Great Firewall of China, GFW) - это распределённая система фильтрации трафика, развёрнутая на международных стыках операторов China Telecom, China Unicom и China Mobile. Единого устройства с таким названием не существует: фильтрацией занимаются десятки узлов на магистральных каналах, а списки блокировок и правила обновляются централизованно. Для DevOps-инженера отсюда следуют три практических вывода. Часть зарубежных сервисов недоступна из материкового Китая полностью, часть работает с потерями пакетов и обрывами, а сборка и деплой в китайском регионе требуют локальных зеркал и легального канала наружу.

По механике GFW ближе к системе активного вмешательства, чем к сетевому экрану. Он не ограничивается отбрасыванием пакетов: подменяет DNS-ответы, подставляет поддельные TCP RST, ограничивает скорость отдельных потоков и анализирует зашифрованный трафик по метаданным. Многие сбои выглядят как проблемы приложения или канала, хотя причина в фильтрации: git clone зависает на середине, docker pull падает по таймауту, SSH-сессия рвётся через 15 секунд после установки.

Административная часть системы опирается на китайское законодательство о кибербезопасности и лицензирование телеком-услуг. Техническая сторона остаётся за операторами связи и профильными ведомствами, поэтому поведение фильтра меняется без публичных анонсов. Дальше разобраны механизмы фильтрации, актуальные блокировки, влияние на рабочие сценарии и законные варианты доступа к корпоративным ресурсам.

Что такое Великий китайский файрвол и зачем он нужен

GFW - комплекс технических и административных мер, который определяет, какой зарубежный трафик доходит до пользователей в материковом Китае. Административная часть включает лицензирование операторов и VPN-провайдеров, требования к хранению логов и реестр запрещённых ресурсов. Техническая часть - фильтрация на магистральных каналах, о ней и пойдёт речь.

Историческая точка отсчёта - государственная программа «Золотой щит» (Golden Shield), запущенная в 1998 году и развёрнутая в масштабах страны к 2003 году. Термин «Великий китайский файрвол» закрепился в западной прессе в начале 2000-х. С 2014 года регулированием интернета занимается Cyberspace Administration of China, а техническая фильтрация остаётся в зоне ответственности Ministry of Public Security и операторов связи.

Заявленные цели системы: ограничение доступа к нежелательному контенту, защита внутреннего рынка (Baidu, WeChat, Weibo и Bilibili занимают ниши, где снаружи работают Google, Meta и X) и снижение зависимости критичной инфраструктуры от зарубежных платформ. Инженеру полезнее смотреть на результат: маршрут трафика до зарубежного сервиса не гарантирован ни по доступности, ни по стабильности задержек.

Ключевые отличия GFW от обычного файрвола

Корпоративный firewall стоит на периметре одной сети и обрабатывает трафик этой сети. GFW работает в транзите, на каналах между автономными системами, и видит потоки миллионов пользователей и организаций. Согласовать исключение у администратора нельзя: единой точки администрирования, доступной извне, у системы нет, а правила применяются ко всем абонентам оператора сразу.

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

Технологии GFW: DNS-фильтрация, блокировка IP, DPI и вмешательство в TCP

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

DNS-фильтрация: как работает и почему её недостаточно

Запросы по UDP/53 перехватываются на стороне оператора. Ответ либо подменяется на NXDOMAIN, либо заменяется адресом из служебного диапазона, который не имеет отношения к реальному сервису. Такие ответы попадают в кэш локального рекурсора с длинным TTL и живут часами, поэтому проблема сохраняется даже после смены сети.

dig +short registry-1.docker.io @8.8.8.8
# вне Китая: адрес из диапазона AWS
# внутри Китая: NXDOMAIN или адрес из служебного блока

DNS over HTTPS и DNS over TLS частично решают задачу, но известные резолверы блокируются по IP и по SNI. Дополнительная сложность с Cloudflare: компания включает ECH по умолчанию, SNI в рукопожатии скрыт, и фильтр реагирует на сам факт обращения к адресам CDN, ограничивая скорость или разрывая соединение. Смена DNS-сервера помогает только на первом шаге и не спасает от DPI и RST-инжекции.

DPI и SNI-фильтрация: почему HTTPS не спасает

При установке TLS-соединения клиент отправляет ClientHello, где имя запрашиваемого хоста (SNI) в классической схеме идёт открытым текстом. Система глубокой инспекции пакетов читает это поле и при совпадении с чёрным списком обрывает сессию до начала передачи данных. Расшифровка трафика не нужна: достаточно метаданных.

Кроме SNI, DPI использует косвенные признаки. Анализируются размеры первых пакетов, тайминги, направление инициатора соединения, энтропия полезной нагрузки, отпечатки TLS-стека (JA3/JA4). Для обнаружения туннелей применяются эвристики: множество доменов от одного клиента за короткое время, длительные потоки к одному IP, нетипичные наборы шифров. Отдельная практика - активное зондирование подозрительных серверов: система сама подключается к узлу и проверяет, отвечает ли он как прокси.

ECH скрывает SNI, однако фильтр адаптировался: блокируются IP-адреса крупных CDN, где размещено множество доменов, а часть трафика замедляется. Наблюдаемый эффект для инженера: сайт на Cloudflare открывается с частичной загрузкой, статика не догружается, API отвечает таймаутами. Для TLS 1.2 в рукопожатии видны сертификаты сервера, поэтому включение TLS 1.3 на своих сервисах усложняет фильтрацию.

Активное вмешательство в TCP: RST-инжекция и разрыв соединений

Когда соединение уже установлено и фильтр распознал запрещённый трафик, обеим сторонам отправляются поддельные TCP RST с корректными номерами последовательности. Клиент и сервер считают, что партнёр разорвал сессию, и закрывают её. Логи выглядят безобидно: Connection reset by peer без внятной причины на стороне приложения.

Симптомы в реальной работе: SSH-туннель держится 5-20 секунд и падает; TLS-рукопожатие проходит, но первая же выгрузка данных рвётся; длинные gRPC-стримы и WebSocket-сессии завершаются на середине. Вместо полного обрыва фильтр может применять throttling: скорость падает до десятков килобайт в секунду, растут RTT и число ретрансмиссий. Такое поведение особенно ломает синхронизацию репозиториев и загрузку образов.

Побочный эффект: под раздачу попадает и легитимный трафик. Именно поэтому GitHub может работать нестабильно, а Google Search, YouTube и Gmail недоступны стабильно: для первых применяется точечное ограничение, для вторых - постоянная блокировка на нескольких слоях сразу.

Какие сервисы и платформы заблокированы в Китае в 2026 году

Список динамический: одни ресурсы блокируются, другие периодически ослабляют. Устойчивые категории к 2026 году выглядят так.

Блокировка обходит стороной локальные версии сервисов: cn.bing.com и InCareer (LinkedIn для Китая) работают, но с ограниченным набором данных и отдельной модерацией. Внутренние альтернативы (WeChat, DingTalk, Gitee, Alibaba Cloud) закрывают повседневные задачи, но несовместимы с привычными CI/CD-цепочками.

Почему GitHub и Docker Hub работают нестабильно

GitHub не закрыт полностью: домены github.com и api.github.com то замедляются, то отвечают нормально, а raw.githubusercontent.com и codeload.github.com блокируются чаще. На практике git clone может идти минутами и упасть на этапе получения объектов, а скачивание релизов по прямой ссылке завершается таймаутом. Длительность и объём соединения играют роль: чем дольше живёт сессия, тем выше шанс поймать RST.

Docker Hub страдает дважды. Само обращение к registry-1.docker.io идёт через CDN, который попадает под ограничение по IP, а манифесты и слои образов качаются долго. Образы Kubernetes из gcr.io недоступны почти всегда, поэтому стандартный сценарий с manifest из upstream-репозитория в китайском кластере заканчивается ImagePullBackOff и перезапусками пода в CrashLoopBackOff. Аналогичная картина с PyPI, npm и proxy.golang.org: устанавливать зависимости из материкового Китая без зеркала непрактично.

Отдельный нюанс - геофильтрация на стороне сервисов. Многие зарубежные платформы сами ограничивают доступ из китайских подсетей, снижая нагрузку и соблюдая санкционные требования. Такое ограничение не связано с GFW, но выглядит для пользователя так же, поэтому при разборе инцидентов стоит различать эти два случая, о чём подробнее написано в материале про геофильтрацию веб-приложений и практические решения для DevOps.

Влияние на Let's Encrypt и сервисы wildcard DNS

Let's Encrypt сам по себе в Китае не заблокирован: API acme-v02.api.letsencrypt.org обычно отвечает. Проблемы возникают на шагах, где нужен корректный DNS или внешнее соединение. При HTTP-01 валидации сервер проверки приходит снаружи, и входящий трафик на 80-й порт должен доходить до площадки. При DNS-01 клиент обязан получить настоящую TXT-запись от своего провайдера, а если резолвер в Китае отдаёт подменённый ответ, проверка не пройдёт. Дополнительно тормозят OCSP и CRL, из-за чего частьTLS-клиентов при отзыве сертификата ждёт ответа десятки секунд.

Сервисы wildcard DNS nip.io и sslip.io, которые встраивают IP-адрес прямо в DNS-имя и обрабатывают десятки тысяч запросов в секунду, в Китае работают ненадёжно. Их авторитетные серверы находятся за пределами страны, а DNS-запрос к ним проходит через тот же фильтр: запрос к .nip.io может вернуть NXDOMAIN, подменённый адрес или таймаут. Второй нюанс связан с Let's Encrypt: nip.io и sslip.io включены в Public Suffix List, поэтому выпустить один wildcard-сертификат на всё имя нельзя, сертификаты выдаются на каждое конкретное имя. Эти же сервисы встречаются в официальной документации Google Cloud (Knative Serving), AWS (EKS, Teleport), Microsoft Azure (Autoscaling AKS microservices), IBM Redbooks и AMD Enterprise AI, поэтому вопрос их доступности актуален не только для домашних лабораторий.

Рабочие альтернативы для китайской площадки: собственный резолвер (dnsmasq или CoreDNS) с локальной зоной, зарегистрированный домен с wildcard-записью и DNS-01 валидацией через провайдера, внутренний домен вроде *.k8s.local для тестовых сред. Такие схемы не зависят от внешних DNS-сервисов и не ломаются, когда фильтр меняет поведение.

Как GFW влияет на работу DevOps-инженеров и бизнеса с Китаем

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

Проблемы с CI/CD и оркестрацией

GitHub Actions не предоставляет раннеров в материковом Китае, а self-hosted раннер внутри страны вынужден обращаться к api.github.com и к хранилищу артефактов, которые периодически недоступны. GitLab CI работает стабильнее, но загрузка больших артефактов часто упирается в троттлинг. Итог: время сборки растёт в разы, часть job падает по таймауту и требует ручного перезапуска.

С оркестрацией ситуация предсказуемее, причина почти всегда одна - образ. Типичная цепочка: kubelet не может скачать pause-образ из gcr.io, под зависает в ImagePullBackOff, после лимита перезапусков переходит в CrashLoopBackOff, а дежурный видит только ошибку в events. Легальные решения выглядят так:

• локальный registry (Harbor или registry от облачного провайдера) с прогревом нужных образов;
• зеркала образов Kubernetes и Docker Hub, доступные внутри страны (например, репозитории Alibaba Cloud, Tencent Cloud и Huawei Cloud);
• containerd и Docker, настроенные на mirror-эндпоинт вместо прямого обращения к upstream;
• собственная сборка базовых образов из локальных баз и хранение их в закрытом реестре.

Инфраструктуру для зеркал и вспомогательных сервисов удобно держать на площадке с предсказуемой сетью, например на облачных серверах Timeweb Cloud с гибким набором ресурсов и хранилищем. Такая площадка подходит для кэширующего прокси, Git-зеркала и реестра образов, которые обслуживают китайские команды через легальный международный канал.

Задержки и нестабильность соединений

Даже доступные сервисы работают медленно. Фильтр применяет throttling к длительным потокам, поэтому загрузка 1 ГБ данных с зарубежного сервера может занимать часы вместо десятков минут. Потери пакетов и скачки RTT ломают очередь TCP-подтверждений, а с ней и скорость любого туннеля.

Что это значит на практике: сборка Docker-образа, тянущего зависимости из интернета, идёт в 5-10 раз дольше; синхронизация ветки репозитория с большим числом объектов завершается таймаутом; резервное копирование в зарубежное хранилище не укладывается в окно обслуживания; gRPC-стримы между сервисами в Китае и за рубежом рвутся без ошибок в логах приложения. Решение однотипно: сокращать объём трафика через границу за счёт локальных кэшей, CDN с точкой присутствия в стране и размещения данных внутри региона.

Легальные способы доступа сотрудников к корпоративным ресурсам из Китая

В Китае законный трансграничный доступ для компаний существует и предоставляется операторами по договору. Физическому лицу такой канал оформить нельзя: лицензию на услугу IP-VPN выдают определённым операторам, и они продают её организациям. Для бизнеса это означает, что канал нужно заказывать, а не «настраивать» самостоятельно.

Корпоративный VPN и выделенные каналы: что выбрать

Корпоративный VPN от лицензированного оператора дешевле выделенной линии, но чувствителен к перегрузкам: вечером скорость проседает, а часть протоколов может замедляться. Выделенный канал (MPLS, IEPL, IPLC) дороже, зато даёт стабильные задержки и гарантированную полосу, что критично для VoIP, видеоконференций и работы с базами данных. Современная альтернатива - SD-WAN с точкой присутствия в Гонконге или Шанхае: политику маршрутизации настраивают на уровне приложения, а не только по IP.

Схему доступа стоит проектировать с разделением трафика: корпоративные подсети идут через туннель, локальные китайские сервисы - напрямую. Это снижает задержки, экономит полосу и уменьшает объём данных, покидающих страну. Практические конфигурации и разбор различий между протоколами собраны в статье про выбор VPN в 2026 году для DevOps и сисадминов, а правила разделения маршрутов описаны в руководстве по настройке split tunneling и защите от утечек DNS.

Локальные зеркала и кэши для разработки

Зеркала снижают зависимость от зарубежных ресурсов и заодно экономят деньги на международном трафике. Минимальный набор для команды в Китае: прокси-реестр контейнеров, зеркала npm, PyPI, Go-модулей и APT-пакетов, кэширующий прокси для Git и артефактов сборки.

• Nexus или Artifactory как единая точка кэша для Maven, npm, PyPI и Docker.
• Harbor для внутренних образов с репликацией из головного реестра по расписанию.
• Локальные зеркала дистрибутивов Linux вместо прямого обращения к зарубежным репозиториям.
• Кэш Git-объектов (например, зеркальный bare-репозиторий), обновляемый по cron из головного офиса.
• Прогрев образов по расписанию, чтобы сборка не ждала загрузки слоёв в момент деплоя.

Эффект измеримый: время сборки сокращается в разы, пайплайны перестают падать из-за недоступности upstream, а инциденты «не собралось из-за сети» уходят из дежурной смены. Настройка и обслуживание таких сервисов на Linux требует уверенного владения systemd, journalctl, правами и сетевыми настройками; базовые команды и приёмы собраны в руководстве по системному администрированию Linux для DevOps и сисадминов.

Юридические риски обхода государственной цензуры в Китае

Китайское законодательство различает корпоративный доступ через лицензированного оператора и самостоятельный обход блокировок. С 2017 года провайдеры VPN обязаны получать лицензию на услуги IP-VPN, а операторы связи должны пресекать незарегистрированные туннели в своих сетях. В 2025 году правила ужесточили: усилили контроль за продажей доступа и расширили требования к провайдерам сообщать о подозрительных туннелях.

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

Что считается нарушением, а что - нет

Легально: корпоративный туннель по договору с лицензированным оператором, аренда международного канала (MPLS, IEPL, SD-WAN у зарегистрированного провайдера), размещение сервисов в китайских облачных регионах, локальные зеркала репозиториев. Рискованно: публичные VPN без лицензии, личные туннели на арендованных зарубежных VPS, прокси-сервисы, купленные в рознице, любые схемы, где трафик компании идёт через неучтённый канал.

Пример из практики: сотрудник филиала в Шанхае поднял личный VPN для доступа к корпоративной почте и Git. Формально он нарушил правила о нелицензированных туннелях, а компания получила риск утечки и несоответствие требованиям к защите данных. Корректный вариант в том же сценарии: подключить офис к каналу оператора, а рабочие репозитории и артефакты держать в локальном кэше внутри страны.

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

Практические рекомендации для DevOps: как подготовить инфраструктуру

Порядок действий для команды, которая работает с китайскими площадками или сотрудниками:

1. Составьте перечень ресурсов, которые нужны сотрудникам в Китае, и отметьте среди них критичные для работы ежедневно.
2. Разверните локальные зеркала для контейнеров, npm, PyPI, Go-модулей и пакетов ОС; настройте прогрев образов по расписанию.
3. Перенесите сервисы, ориентированные на китайских пользователей, в местные облачные регионы, а трансграничным оставьте только обмен служебными данными.
4. Оформите легальный корпоративный канал или выделенную линию у лицензированного оператора и настройте разделение трафика.
5. Включите TLS 1.3 на своих сервисах и держите актуальные цепочки сертификатов, чтобы сократить число рукопожатий с внешними проверками.
6. Проверьте доступность инфраструктуры изнутри Китая и продолжайте измерения постоянно.
7. Обучите сотрудников: только одобренные IT-отделом инструменты, никаких личных туннелей для рабочих данных.
8. Документируйте каждое изменение и пересматривайте его при смене поведения фильтра.

Тестирование доступности и мониторинг

Проверки из Европы или США ничего не говорят о доступности из Китая. Нужны собственные точки мониторинга: небольшая виртуальная машина в шанхайском регионе китайского облака или в Гонконге и набор проверок по расписанию.

Что измерять: корректность DNS-ответа (сравнение с эталонным резолвером), время установки TLS-соединения, время до первого байта, долю успешных git clone и docker pull, объём выгруженных данных за интервал. Полезно логировать поведение по часам: часть ограничений проявляется в вечерний пик. Изменение этих метрик служит ранним сигналом, что фильтр ужесточил правила, и позволяет заменить канал до того, как дежурный начнёт разбирать упавшие пайплайны.

Вспомогательные сервисы для кэша и мониторинга разумно размещать на площадке рядом с точкой присутствия, например на инфраструктуре Timeweb Cloud, и связывать её с китайскими регионами через легальный канал.

Заключение: что учитывать при работе с Китаем в 2026 году

GFW - многослойная система: DNS-фильтрация ломает разрешение имён, чёрные списки IP закрывают адреса и подсети, DPI разбирает метаданные TLS и находит туннели, RST-инжекция рвёт уже установленные соединения. Отдельного «правила», отключив которое можно получить стабильный доступ, не существует. Список заблокированных сервисов меняется, а поведение фильтра отличается у разных операторов и в разное время суток.

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

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