Shadowrocket не подключается: что проверить в ключе, сервере и DNS

Почему Shadowrocket не подключается

Утилита для iPhone, iPad и других устройств Apple умеет работать с разными типами прокси и поддерживает DNS over HTTPS, DNS over TLS и DNS over QUIC, поэтому причин у сбоя несколько: от неверного формата ссылки импорта до проблем с TLS-параметрами и разрешением домена. По описанию в App Store приложение также умеет импортировать конфиги по URL и из iCloud Drive, а значит ошибки нередко приходят вместе с готовой подпиской или чужим ключом, а не вводятся вручную. Точный набор доступных функций и поведение отдельных протоколов могут отличаться в зависимости от версии приложения и конфигурации сервера.

На практике есть три основные зоны проверки:

• сам ключ или профиль подключения;
• доступность и корректность сервера;
• DNS и сопутствующие сетевые настройки.

Если разделить проблему именно так, искать причину становится заметно проще.

Что проверить в первую очередь

Перед разбором тонких настроек полезно исключить базовые вещи. Очень часто соединение не поднимается из-за одного неверного символа в адресе, порте, UUID, пароле или public key. Для конфигураций с TLS критичны servername или SNI: если поле пустое или указано неверно, соединение может не установиться. В документации по TLS для современных конфигов на базе sing-box и совместимых клиентов отдельно отмечено, что значение SNI или servername должно соответствовать ожидаемой стороне сервера; при несовпадении соединение может завершаться с ошибкой.

1. Откройте профиль и сравните адрес сервера, порт, тип протокола и способ шифрования с исходными данными от провайдера конфигурации.
2. Проверьте, не истек ли ключ или подписка и не отключен ли сервер на стороне провайдера.
3. Убедитесь, что домен сервера вообще резолвится в IP-адрес и открывается по сети.
4. Если используется TLS, перепроверьте SNI, servername, ALPN и дополнительные поля вроде public key или short ID, если они предусмотрены вашей схемой.
5. Отключите на время лишнюю экзотику: кастомные правила, локальные хосты, сторонние DNS-серверы и экспериментальные параметры.

Если после этого ситуация не меняется, уже есть смысл разбирать, что именно сломано: ключ, сервер или DNS.

Ошибки в ключе и конфиге

Неправильный формат ссылки импорта

Профиль может импортироваться, но содержать ошибочные или неполные поля. Это особенно часто встречается у конфигов из сомнительных источников, старых подборок и случайных Telegram-каналов. Если после импорта запись появилась, это еще не значит, что все параметры корректны.

Проверьте следующее:

• совпадает ли тип протокола с тем, что реально выдал сервер;
• не потерялись ли символы в пароле, UUID, токене или public key;
• не заменились ли спецсимволы при копировании;
• нет ли лишних пробелов в имени хоста, SNI или пути WebSocket;
• не подставился ли неверный порт.

Поля TLS, SNI и servername

Для соединений с TLS именно эти поля часто оказываются причиной отказа. В документации по TLS-конфигам указано, что SNI или servername задает имя, которое клиент предъявляет серверу; если поле пустое, оно может браться из адреса server. Но когда на сервере ожидается конкретное имя, неправильное значение приводит к срыву рукопожатия. Это особенно критично в схемах VLESS, VMess, Trojan и близких конфигурациях.

Проверьте:

• совпадает ли servername с доменом, который ожидает сервер;
• не перепутаны ли поля адреса сервера и SNI;
• не указан ли IP там, где сервер ожидает доменное имя;
• не включена ли проверка сертификата при неподходящем сертификате на стороне сервера;
• не конфликтует ли ALPN с серверной настройкой, если это поле задавалось вручную.

Дополнительные параметры у сложных схем

Если конфиг использует Reality, XTLS, WebSocket или другие дополнительные обвязки, одна ошибка в служебном поле ломает все подключение. Для Reality критичны public key и short ID, а для WebSocket — путь и заголовок Host, если сервер их требует. Тут нельзя гадать: нужно сверять каждый параметр с исходной конфигурацией сервера или с данными провайдера доступа.

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

Что смотреть на стороне сервера

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

Сервер отвечает или нет

Нужно понять, доступен ли сам узел:

• разрешается ли домен сервера в IP;
• достижим ли нужный порт;
• не изменился ли IP у домена после переезда;
• не истек ли сертификат, если используется TLS;
• не отключен ли конкретный пользователь или ключ.

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

Несовпадение протокола и серверной схемы

Одна из самых неприятных ошибок — когда профиль выглядит правдоподобно, но клиент и сервер настроены на разные режимы. Например, сервер уже переведен на другую схему TLS, изменен путь WebSocket, обновлен UUID или заменен пароль. Внешне это выглядит как вечное подключение без результата или мгновенный сброс.

Если конфигурация выдавалась давно, попросите новый ключ. Если это ваша инфраструктура, перепроверьте последние изменения на сервере: сертификаты, адрес, SNI, транспорт, порт, DNS-записи и права пользователя.

Как понять, виноват ли DNS

Shadowrocket поддерживает локальное сопоставление DNS и несколько защищенных вариантов резолвинга, включая DoH, DoT и DoQ. Это удобно, но именно из-за этого DNS-часть иногда ломает подключение: один сервер не отвечает, другой выдает не тот адрес, а третий конфликтует с текущей сетью.

Признаки, что проблема может быть в DNS:

• по IP соединение работает, а по домену нет;
• одна сеть работает, другая нет;
• в браузере серверное имя не открывается или открывается через раз;
• после смены DNS в приложении ситуация меняется;
• подключение к профилю есть, но сайты или сервисы не начинают загружаться.

Что проверить в DNS-настройках

1. На время диагностики верните системный DNS вместо сложной пользовательской схемы.
2. Если был включен DoH или DoT, временно отключите его и проверьте, меняется ли поведение.
3. Убедитесь, что домен сервера резолвится одинаково в текущей сети и через мобильный интернет.
4. Проверьте, не остались ли старые локальные записи Host или правила, которые подменяют адрес.
5. Если используется профиль с готовыми правилами, исключите ошибку в самом rule set или DNS-блоке подписки.

Смысл здесь простой: сначала упростить DNS-цепочку до минимальной рабочей схемы, а уже потом возвращать дополнительные настройки.

Таблица быстрой диагностики

Безопасный порядок действий

Когда соединение не поднимается, лучше двигаться от простого к сложному. Это экономит время и снижает риск испортить рабочие настройки еще сильнее.

1. Создайте копию текущего профиля.
2. Проверьте адрес сервера, порт, пароль, UUID, public key и short ID, если они используются.
3. Сверьте SNI или servername с тем, что должен ожидать сервер.
4. Временно отключите нестандартный DNS и дополнительные правила.
5. Проверьте тот же профиль в другой сети: Wi‑Fi и мобильный интернет.
6. Если есть возможность, протестируйте другой рабочий сервер того же провайдера.
7. Если не помогает, запросите новый ключ или новый URL подписки.

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