# Почему сообщения с одноразовым паролем (OTP) не доставляются — и как исправить проблемы с их доставкой

> Одноразовые пароли (OTP) не срабатывают по ограниченному списку причин: отклонение идентификатора отправителя, небезопасные маршруты, ограничение скорости, контентные фильтры, кодировка, перегрузка сети. Руководство по диагностике и устранению неполадок для инженера-практика.

- Канонический URL: https://www.broadnet.me/ru/blog/why-otp-messages-fail-delivery-troubleshooting
- Язык: ru
- Последнее обновление: 2026-09-30
- Издатель: BroadNet (https://www.broadnet.me)

- Опубликовано: 2026-05-20
- Автор: BroadNet Engineering

Когда одноразовый пароль не приходит, пользователь застревает на экране входа в систему или оформления заказа и находится всего в одном шаге от отказа от покупки. Для команды разработчиков неприятно то, что сообщение часто отправляется корректно — API возвращает код 202, отправка SMPP-запроса принята, платформа отображает сообщение в очереди. Сбой происходит где-то на нижестоящем уровне, который команда разработчиков приложения не может увидеть напрямую. В этой статье рассматривается конечный список причин сбоев одноразовых паролей в производственной среде, как отличить их от имеющихся чеков и каковы схемы устранения проблемы для каждой из них.

## Площадь поверхности разрушения меньше, чем кажется.

Сбой передачи OTP-трафика происходит по одной из семи причин, примерно в таком порядке частоты: отклонение идентификатора отправителя у оператора назначения, пропуск сообщения через «серый маршрут», ограничение скорости на SMSC или межсетевом экране, срабатывание контентных фильтров на шаблоне, несоответствие кодировки между содержимым UCS-2 и шаблоном GSM-7, перегрузка сети у оператора назначения и недоступность самого телефона (выключен, вне зоны покрытия, переадресация с устаревшей маршрутизацией). Все остальное — поврежденный MSISDN, просроченные учетные данные, события обрыва маршрута — составляет небольшое меньшинство. В первую очередь следует диагностировать наиболее распространенные случаи.

## Внимательно изучите отчёты о доставке, а не ответ на отправленное сообщение.

Самая большая ошибка, которую допускают команды, — это рассматривать успешную отправку (код 202 от HTTP, ESME_ROK в submit_sm) как доказательство доставки сообщения. Это не так. Отправка означает, что платформа приняла сообщение; доставка означает, что устройство его получило. Каждая система OTP должна быть связана с [отчётом о доставке](https://www.broadnet.me/answers/what-is-dlr) (DLR), который поступает позже в виде веб-хука или PDU deliver_sm и содержит один из небольшого набора кодов состояния: DELIVRD, UNDELIV, REJECTD, EXPIRED, UNKNOWN. Первым сигналом для любого расследования OTP является распределение статуса DLR по маршруту, идентификатору отправителя, оператору назначения и временному окну, а не процент успешных отправок.

## Проведите диагностику, определив место возникновения неисправности.

Чистое расследование с использованием одноразового пароля (OTP) разделяет сбой на четыре сегмента и работает в обратном порядке, начиная с самого нижнего сигнала. Сегмент 1: сбой при отправке — платформа отклонила вызов до того, как он был отправлен, почти всегда из-за некорректного идентификатора отправителя, незарегистрированной категории шаблона, неподдерживаемой страны или отсутствия обязательного поля. Сегмент 2: принят при отправке, но так и не доставлен в целевой SMSC — обычно из-за проблемы с качеством маршрутизации или блокировки брандмауэром. Сегмент 3: доставлен в SMSC и вернул отрицательный DLR — контент отфильтрован, идентификатор отправителя занесен в черный список оператора, получатель заблокирован. Сегмент 4: положительный DLR, но пользователь не сообщает о сообщении — телефон выключен, перенесен к другому оператору с устаревшей маршрутизацией, спам-фильтр на уровне ОС или уведомление подавлено. Способы устранения проблемы различаются в каждом сегменте; смешивание их может привести к неправильному решению.

## Семь распространенных причин и что делать в каждом случае.

### 1. Отклонение идентификатора отправителя

На многих регулируемых рынках — ОАЭ в рамках TDRA, Саудовская Аравия в рамках CST, Египет в рамках NTRA, Индия в рамках DLT TRAI — требуется предварительная регистрация каждого буквенно-цифрового идентификатора отправителя в отношении проверенного юридического лица. Трафик, отправленный под незарегистрированным идентификатором, отклоняется на границе оператора и приводит к отрицательному DLR без доставки сообщения, но с ответом на запрос 202. Решение заключается в регистрации, а диагностика состоит в сопоставлении UNDELIV/REJECTD с идентификатором отправителя и страной назначения: если все ошибки связаны с одним и тем же идентификатором отправителя в одной стране, проблема в регистрации. См. [руководство по регистрации идентификаторов отправителей для рынков стран Персидского залива](https://www.broadnet.me/blog/sender-id-registration-guide-gcc-markets) для получения подробной информации о необходимых документах.

### 2. Пересадки по «серым» маршрутам

Дешевые международные маршруты часто включают один или несколько переходов через партнерские агрегаторы или терминалы SIM-ферм. Каждый переход увеличивает задержку, повышает вероятность скрытого обрыва соединения и увеличивает вероятность того, что межсетевой экран оператора назначения классифицирует трафик как несанкционированный A2P и блокирует его. Характерными признаками являются высокая частота UNDELIV, высокая вариативность задержки и резкое падение скорости доставки, когда оператор назначения развертывает или обновляет [SMS-межсетевой экран](https://www.broadnet.me/answers/what-is-sms-firewall). Решение заключается в переносе OTP на прямой маршрут оператора; компромисс обсуждается в [прямые маршруты против серых маршрутов](https://www.broadnet.me/blog/direct-routes-vs-grey-routes-a2p-sms).

### 3. Регулирование скорости на уровне SMSC или межсетевого экрана.

Каждый оператор и каждый межсетевой экран устанавливают потолок количества отправленных сообщений в секунду (TPS) для каждого идентификатора отправителя и каждого маршрута. При превышении этого потолка сообщения либо немедленно отклоняются (в лучшем случае — вы видите сбой), либо ставятся в очередь и доставляются с задержкой (в худшем случае — они приходят после истечения срока действия OTP, и пользователь уже отказался от дальнейшего взаимодействия). Диагностика заключается в сравнении пиков отправки с задержкой p95: стабильная кривая задержки при постоянной нагрузке, которая резко возрастает во время пиков, указывает на ограничение скорости. Решение состоит в ограничении скорости на уровне приложения для сглаживания пиков и согласовании более высокого потолка TPS специально для трафика класса OTP.

### 4. Фильтры контента

Классификаторы содержимого операторов и межсетевых экранов могут выявлять шаблоны одноразовых паролей (OTP), содержащие ключевые слова, URL-адреса (большинство операторов активно борются с непроверенными короткими ссылками в транзакционном контенте), необычные имена отправителей или макеты, напоминающие известные фишинговые схемы. Характерной чертой является внезапное увеличение количества отклоненных запросов (REJECTD) в одном шаблоне, в то время как все остальные запросы обрабатываются без проблем. Решение заключается в гигиеничности шаблона: короткий, стандартный текст OTP, отсутствие коротких ссылок, отсутствие формулировок, создающих ощущение срочности. Если шаблон регулируется (на некоторых рынках транзакционные шаблоны должны быть предварительно зарегистрированы), убедитесь, что зарегистрированная версия соответствует отправляемой версии — небольшие расхождения будут обнаружены.

### 5. Несоответствие кодировки

Шаблоны OTP, содержащие символы, не являющиеся символами ASCII (гласная с диакритическим знаком, специальная кавычка, скопированная из проектной документации, арабская цифра), незаметно преобразуют сообщение из GSM-7 в UCS-2, уменьшая допустимое количество символов на сегмент со 160 до 70 и вызывая объединение сообщений, которые некоторые старые телефоны неправильно компилируют. Диагностика заключается в проверке фактического сгенерированного шаблона побайтно, а не шаблона в том виде, в котором его видит разработчик. Решение состоит в проверке шаблона с учетом кодировки и проверке во время сборки, которая выявляет любые символы, не являющиеся символами GSM-7, в транзакционном шаблоне.

### 6. Перегрузка сети

В периоды крупных событий (Ид, Черная пятница, национальные праздники, масштабные сбои) каналы SMSC операторов-получателей иногда дают сбой — заявки принимаются, но задержки доставки возрастают от долей секунды до многих минут. На стороне отправителя нет простого решения; задача состоит в обнаружении проблемы (резкий рост задержки p95 по всем маршрутам к одному оператору) и переключении на альтернативный канал до закрытия окна OTP.

### 7. Телефон недоступен

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

## Создайте диагностическую панель один раз и используйте её постоянно.

Большинство расследований OTP-запросов заходят в тупик, потому что команда работает с необработанными логами под давлением. Команды, которые быстро восстанавливаются, используют постоянную панель мониторинга с пятью виджетами: распределение статуса DLR по операторам назначения (самый полезный график), сквозная задержка p50/p95/p99 для каждого маршрута, скорость доставки на уровне идентификатора отправителя, скорость доставки на уровне шаблона контента и временной ряд от отправки до доставки в реальном времени за последний час. Создайте эти инструменты один раз. Они определяют разницу между диагностикой за сорок минут и за четыре часа.

## Эффективные методы устранения проблем

### Прямая привязка только для OTP.

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

### Резервная цепочка, автоматическая и с ограничением по времени.

При проектировании системы учитывалось предположение, что любой отдельный канал может иногда давать сбои, и соответствующим образом разрабатывалась цепочка резервных вариантов: сначала шаблон аутентификации WhatsApp или RCS, если пользователь доступен по любому из этих каналов, SMS в качестве универсального резервного варианта, голосовой OTP в качестве последнего средства. Резервный вариант должен быть автоматическим (без повторной попытки вручную со стороны пользователя), ограниченным по времени (время ожидания до переключения на резервный канал короче, чем время ожидания пользователя — обычно от 8 до 15 секунд) и условным (не переключаться на резервный канал при положительном значении DLR; переключаться на резервный канал при истечении времени ожидания или отрицательном значении DLR). Сам код OTP должен генерироваться один раз и использоваться повторно на разных каналах, чтобы пользователю не предоставлялись два действительных кода.

### Исключайте дубли при каждой повторной попытке

Когда пользователь нажимает «повторная отправка» или приложение автоматически повторяет попытку, проверяйте, прежде чем отправлять снова. API BroadNet не принимает ключ идемпотентности, поэтому дедупликация — задача вашего кода: фиксируйте каждую отправку до её выполнения, сохраняйте идентификатор сообщения, который возвращает API, и проверяйте статус этого сообщения перед любой повторной отправкой (см. [идемпотентность и безопасные повторы](https://www.broadnet.me/developers/idempotency)). Без такой проверки медленная, но успешная первая отправка и автоматическая повторная отправка приведут к появлению двух одноразовых паролей в почтовом ящике пользователя, пользователь использует более старый, проверка не удается, и команда обвиняет службу OTP, хотя ошибка заключалась в логике повторных попыток.

### Голосовой резерв для длинного хвоста

Примерно один процент пользователей в любой конкретный день не получает SMS-сообщение ни по одной из вышеперечисленных причин, и этот один процент — это тот, кто в основном обращается в службу поддержки. [Голосовой OTP](https://www.broadnet.me/products/myotp) — звонок, в котором код зачитывается вслух, — решает почти все эти проблемы. Это разница между раздраженным пользователем, который пробует другой браузер, и растерянным пользователем, который сдается.

> Сервис BroadNet [OTP](https://www.broadnet.me/products/otp) обрабатывает прямую привязку, цепочку резервных соединений и эскалацию голосовой связи за одним вызовом API, возвращает идентификатор сообщения, который можно проверить перед повторной отправкой — и предоставляет информацию о распределении DLR по каналам и операторам, на которой основано приведенное выше руководство по диагностике.

## Как выглядит хороший результат в цифрах

Хорошо оснащенная система OTP, отправляющая сообщения на регулируемый рынок стран Персидского залива по прямым маршрутам операторов и имеющая работающую резервную цепочку, должна обеспечивать: 99%+ сквозной проверки (пользователь успешно подтвердил получение сообщения, а не просто его доставку), задержку p95 менее пяти секунд на основном канале и измеримую, но небольшую (1-3%) вероятность перехода на резервный канал. Если ваши показатели существенно хуже, проблема почти наверняка связана с одной из семи причин, перечисленных выше — диагностируйте, а не гадайте.

## Рекомендуемая литература

- [SMS API против SMPP — что лучше для предприятий?](https://www.broadnet.me/blog/sms-api-vs-smpp-enterprise-decision-guide)
- [Как банкам следует отслеживать доставку OTP-кодов и мошенничество](https://www.broadnet.me/blog/bank-otp-delivery-monitoring-fraud-playbook)
- [Как экспресс-верификация звонков влияет на доходы операторов A2P](https://www.broadnet.me/blog/flash-call-verification-operator-a2p-revenue-impact)
- Глоссарий — [что такое OTP](https://www.broadnet.me/answers/what-is-otp), [что такое DLR](https://www.broadnet.me/answers/what-is-dlr), [что такое проверка Flash-Call](https://www.broadnet.me/answers/what-is-flash-call-verification)
- Страницы продуктов — [Сервис OTP](https://www.broadnet.me/products/otp) и [Голосовой OTP MyOTP](https://www.broadnet.me/products/myotp)
- Покрытие — [Маршрутизация A2P SMS и OTP в ОАЭ](https://www.broadnet.me/coverage/uae)