Начните бесплатный 3-дневный пробный период
Зарегистрируйтесь и попробуйте все премиум-функции бесплатно.
*Только для новых пользователей. Один пробный период на пользователя.
Работает ли Azure Portal в Китае? Доступ и тенант
Jason Chen
12 сентября 2026 г.· 9 мин чтения
Работает ли Azure Portal в Китае? Сначала установите, каким облаком Azure и каким тенантом вы пользуетесь. Глобальный Azure и Microsoft Azure под управлением 21Vianet — отдельные среды с разными порталами и конечными точками идентификации. Поэтому доступ к одной среде не доказывает наличие аккаунта или ресурсов в другой.
Ключевые выводы:
- До диагностики уточните, нужен ли
portal.azure.comилиportal.azure.cn.- Глобальный Azure и Azure China имеют отдельные аккаунты, тенанты, подписки, конечные точки и каталоги сервисов.
- Ошибку тенанта, подписки или RBAC нельзя исправить сменой сетевого маршрута.
- Проверяйте точный сервис и регион, а не считайте два облака одинаковыми.
- До поездки выполните задачу только для чтения и подтвердите утверждённый резервный путь администратора.
Материал относится к плоскости управления Azure. Работа коммуникационного сервиса разобрана отдельно в статье о Microsoft Teams в Китае, а общие проблемы портала авторизации, DNS и маршрутизации — в диагностике сайтов материкового Китая.
Работает ли Azure Portal в Китае и какой портал вы открываете?
Microsoft описывает Azure в Китае как физически изолированное облако под управлением 21Vianet. Оно использует другие URL и требует отдельного аккаунта.［1］ В документации по национальным облакам также указаны отдельные узлы авторизации и адреса порталов.［2］
Это базовая развилка, а не редкое исключение. Глобальный аккаунт Microsoft Entra, который открывает portal.azure.com, не даёт автоматического доступа к portal.azure.cn. Подписка глобального Azure не появится в тенанте Azure China; гостевое приглашение и назначение роли не переносятся из одной среды в другую.
| Слой | Свидетельство | Ошибочное толкование | Ответственный |
|---|---|---|---|
| Сеть | Портал не отвечает, соединение сбрасывается или не загружаются ресурсы страницы | «Тенант удалён» | Диагностика сети или конечной точки |
| Учётная запись и тенант | Неверный центр авторизации, аккаунт не найден, гостевой доступ, MFA или Conditional Access | «Портал заблокирован» | Администратор идентификации тенанта |
| Подписка и RBAC | Подписка отсутствует, раздел запрещён или не хватает разрешения | «Нужен другой URL» | Владелец подписки или администратор RBAC |
| Сервис и регион | Недоступны поставщик ресурсов, функция, SKU, квота или регион | «Azure China копирует глобальный Azure» | Владелец рабочей нагрузки и актуальный каталог |
Запишите нужное облако, идентификаторы тенанта и подписки, группу ресурсов, сервис и регион. Не сохраняйте маркер доступа, маркер обновления, секрет клиента или полный диагностический архив в дорожных заметках.
Чем глобальный Azure отличается от Azure China?
Эти среды разделены операционно и коммерчески. Microsoft указывает, что Azure China независимо управляется и продаётся 21Vianet.［1］ Приложение должно использовать конечную точку своего национального облака: регистрация приложения, настроенная только для глобального центра авторизации, не может отправить тот же запрос маркера в китайское облако.［2］
Доступность сервисов тоже различается. Microsoft ведёт отдельные региональные документы и каталог Azure China, а не обещает точную копию глобального набора.［3］［4］ Одинаковое имя сервиса не гарантирует одинаковые версии API, набор функций, SKU, квоты, предварительные возможности или интеграции.
На практике закладка может вести не в тот портал; скрипт — обращаться к глобальной конечной точке управления или идентификации; гостя могли пригласить в другой тенант; шаблон — ссылаться на отсутствующего поставщика ресурсов или версию API; выбранному региону может не хватать сервиса или мощности.
Не создавайте вторую подписку или регистрацию приложения без владельца рабочей нагрузки. Дублирующиеся ресурсы создают проблемы с оплатой, идентификацией, размещением данных и управлением, а исходная задача так и остаётся нерешённой.
Как проверить Azure до поездки?
Выполните безопасную последовательность для нужного облака:
- Откройте правильный домен портала в управляемом браузере.
- После входа проверьте каталог и идентификатор тенанта.
- Выберите нужную подписку и проверьте её состояние.
- Откройте известную группу ресурсов и обзор одного ресурса без изменений.
- Просмотрите журнал действий либо другую разрешённую страницу только для чтения.
- Уточните сервис и регион в актуальной документации именно этого облака.
- Подтвердите резервного администратора или утверждённый путь через CLI для срочной работы.
Если организация применяет Conditional Access, Privileged Identity Management, корпоративное устройство или бастион, тестируйте тот же процесс. Не ослабляйте эти средства защиты ради того, чтобы тест перед поездкой прошёл успешно. Подходящим резервом может быть дежурный коллега в утверждённой среде, а не личное устройство с новым маршрутом.
Сохраните имя узла портала, идентификаторы тенанта, подписки, ресурса и корреляции, время UTC и точный текст ошибки. Идентификатор корреляции помогает отследить запрос к плоскости управления, но не заменяет подтверждение облака.
Как отделить идентификацию и RBAC от связи?
Сбой идентификации обычно возникает при поиске аккаунта, выборе центра авторизации, MFA, Conditional Access или гостевом доступе. Ошибка подписки или RBAC появляется после входа и называет область, действие, роль или ресурс. Если портал показывает тенант и другие разрешённые ресурсы, отдельный отказ в доступе вряд ли объясняется сетью.
Администратор должен проверить тип субъекта — участник, гость, субъект-служба или управляемое удостоверение; назначена ли роль на группу управления, подписку, группу ресурсов или ресурс; активирована ли привилегированная роль; влияют ли запрещающее назначение, политика, блокировка или регистрация поставщика; тем ли аккаунтом принято приглашение.
Не переключайте каталоги многократно, не принимайте новые приглашения и не просите роль Owner как универсальное решение. Принцип минимальных привилегий остаётся важным и в поездке. Сообщите администратору точную операцию только для чтения, которая вам нужна, чтобы он подобрал наименьшую подходящую роль.
Как проверить сервис и регион?
Пользуйтесь документацией нужного облака. Страница регионов Azure China перечисляет его регионы, а каталог доступности сервисов — продукты.［3］ Наличие региона не означает присутствие всех глобальных функций; географически близкий глобальный регион не становится площадкой китайского облака.
Проверьте поставщика ресурсов, тариф, версию API, зависимости, квоту и ограничения предварительных функций. Раздел портала может отображаться, хотя создание ресурса в подписке или регионе недоступно. Возможна и обратная ситуация: API работает, а конкретный раздел не загружается.
Для существующей рабочей нагрузки читайте регион из конфигурации, а не выводите его из местоположения пользователя или домена портала. Плоскость управления, центр идентификации, плоскость данных и пользовательская конечная точка могут идти разными путями. Миграция — архитектурное решение, а не обход ошибки портала.
Что делать при частичной загрузке портала?
Сначала зафиксируйте симптом: имя узла портала, первый неудачный запрос, если его можно безопасно увидеть, затронутый раздел, облако, тенант и время. Сравните ту же задачу только для чтения через одну утверждённую альтернативную сеть или административный путь.
Не отключайте защиту браузера, не импортируйте неизвестный сертификат, не ставьте неутверждённое расширение и не загружайте HAR с маркером доступа. Если проблема локализована в сетевом пути, а использование VPN законно и разрешено вашей организацией, для авторизованного подключения к Azure Portal можно рассмотреть AethoVPN. Он не выбирает национальное облако, не создаёт аккаунт Azure China, не проходит Conditional Access, не выдаёт права RBAC, не регистрирует поставщика ресурсов и не добавляет мощности.
Если запрос через API или CLI проходит, а один раздел портала не работает, сохраните сведения о разделе и корреляции и используйте утверждённый административный путь. Одинаковая ошибка у нескольких авторизованных пользователей через заведомо рабочие пути требует проверки Azure Service Health или обращения в поддержку, а не изменения тенанта.
Когда остановиться и передать проблему?
Прекратите сетевые изменения, если ошибка указывает неверный тенант, отсутствующую подписку, недопустимую аудиторию, Conditional Access, MFA, RBAC, поставщика ресурсов, квоту, политику, блокировку или неподдерживаемый регион. Это решения плоскости управления и корпоративного контроля.
Проблемы идентификации и гостевого доступа передайте администратору тенанта, RBAC и блокировок — владельцу подписки или ресурса, сервиса и региона — владельцу рабочей нагрузки, воспроизводимый сбой платформы — поддержке Microsoft. Передавайте лишь минимальный обезличенный контекст без пароля, маркера доступа, секрета клиента, закрытого ключа и кода MFA.
Если пользовательское приложение недоступно, а портал работает нормально, диагностируйте приложение отдельно. Благополучный обзор ресурса не доказывает, что DNS, собственный домен, правило межсетевого экрана, частная конечная точка или аутентификация приложения работают из сети материкового Китая.
Итоги
- Сначала определите облако Azure и домен портала.
- Разделяйте идентификацию тенанта, подписку, RBAC, сервис и регион.
- Выполняйте безвредный тест только для чтения с реальными организационными мерами защиты.
- Не создавайте дубликаты и не ослабляйте защиту как временный ремонт.
- Передавайте обезличенные идентификаторы и данные корреляции правильному владельцу.
Часто задаваемые вопросы (FAQ)
Одинаковы ли portal.azure.com и portal.azure.cn?
Нет. Они обслуживают разные облака Azure. Azure China работает под управлением 21Vianet и использует отдельные конечные точки идентификации и сервисов.
Может ли глобальный аккаунт Azure войти в Azure China?
Не автоматически. Microsoft требует отдельный аккаунт для Azure China; конкретную схему должен подтвердить администратор китайского облака.［1］
Почему после входа нет подписки?
Возможно, выбрано неверное облако или каталог, используется другой аккаунт, отсутствует доступ либо подписка находится в ином тенанте. Проверьте идентификаторы, прежде чем менять сетевые настройки.
Исправит ли VPN ошибку Azure RBAC?
Нет. RBAC управляет авторизацией на уровне группы управления, подписки, группы ресурсов или отдельного ресурса. Сетевой маршрут не выдаёт разрешения.
Все ли глобальные сервисы Azure доступны в Azure China?
Нет. Microsoft ведёт отдельный каталог доступности сервисов для Azure China. Перед проектированием или развёртыванием рабочей нагрузки проверяйте актуальные сервис, SKU, версию API и регион.［3］
Работающий портал доказывает работу приложения в Китае?
Нет. Портал относится к плоскости управления. DNS, общедоступная или частная конечная точка, межсетевой экран, идентификация, CDN и региональный путь приложения проверяются отдельно.
Какие данные безопасно передать поддержке Azure?
Передайте облако, обезличенный контекст тенанта и подписки, уместные идентификаторы ресурса и корреляции, время UTC, действие и результат сравнения только для чтения. Никогда не отправляйте пароль, маркер доступа, секрет клиента, закрытый ключ или код MFA.
Отказ от ответственности: Материал содержит общую техническую и туристическую информацию, а не юридическую консультацию или консультацию по соответствию требованиям, идентификации и облачной архитектуре. Сеть, сервисы, политики тенанта и регионы могут меняться.
Источники
- Microsoft Learn, Microsoft Azure in China: https://learn.microsoft.com/en-us/azure/china/overview-operations
- Microsoft Learn, Microsoft Entra authentication and national clouds: https://learn.microsoft.com/en-us/entra/identity-platform/authentication-national-cloud
- Microsoft Learn, Azure in China regions: https://learn.microsoft.com/en-us/azure/china/overview-regions
- Microsoft Learn, Azure China service availability: https://learn.microsoft.com/en-us/azure/china/concepts-service-availability
Sources checked 12 сентября 2026 г.
