NSURLErrorDomain -1001: время ожидания запроса истекло

Константа timed out обозначает, что запрос был отправлен, но полный ответ не пришёл за отведённое время. У приложений по умолчанию стоят ограничения: на ожидание первого ответа и на общую длительность. Когда лимит превышен, система прерывает операцию и выдаёт -1001.

Важно: код не говорит, где была задержка. Она могла возникнуть в вашей сети, у провайдера, на пути к серверу или в самом приложении сервера.

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

Чаще всего виноват медленный или нестабильный канал: слабый сигнал сотовой сети, перегруженный Wi-Fi, потери пакетов. На втором месте перегрузка или медленная работа сервера, особенно при тяжёлых запросах. Затем идут DNS-задержки, промежуточный сервер, сторонний сетевой профиль с большим временем ответа.

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

Проверьте скорость и стабильность соединения: откройте несколько сайтов, запустите видео. Переключитесь между Wi-Fi и сотовой сетью. Подойдите ближе к роутеру. Выключите режим низкого объёма данных, если он включён, и отключите сторонний сетевой профиль.

Если проблема только в одном приложении, повторите попытку позже: возможна перегрузка сервиса. Обновите приложение и систему, перезапустите устройство. При работе через общественный Wi-Fi убедитесь, что вход в сеть подтверждён.

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

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

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

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

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

Мобильная связь по своей природе менее стабильна: слабый сигнал, переходы между сотами, перегрузка вышки в часы пик. Запрос может «зависнуть» на время, превышающее лимит, хотя обычный сайт откроется. Проверьте уровень сигнала, отключите режим экономии и попробуйте перейти на другой стандарт связи, если устройство позволяет.

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

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