Ошибка домена = NSURLErrorDomain Code = -1005 «Сетевое соединение потеряно».

268

У меня есть приложение, которое отлично работает на Xcode6-Beta1 и Xcode6-Beta2 с iOS7 и iOS8. Но с Xcode6-Beta3, Beta4, Beta5 у меня возникают проблемы с сетью в iOS8, но на iOS7 все работает нормально. Я получаю ошибку "The network connection was lost.". Ошибка заключается в следующем:

Ошибка: Ошибка Домен = NSURLErrorDomain Код = -1005 «Сетевое соединение потеряно». UserInfo = 0x7ba8e5b0 {NSErrorFailingURLStringKey =, _kCFStreamErrorCodeKey = 57, NSErrorFailingURLKey =, NSLocalizedDescription = Сетевое соединение было потеряно., _KCFStreamErrorDomainKey = 1, соединение NSUnder0e0707) 07.

Я использую AFNetworking 2.x и следующий фрагмент кода для выполнения сетевого вызова:

AFHTTPRequestOperationManager *manager = [AFHTTPRequestOperationManager manager];
[manager setSecurityPolicy:policy];
manager.requestSerializer = [AFHTTPRequestSerializer serializer];
manager.responseSerializer = [AFHTTPResponseSerializer serializer];

[manager POST:<example-url>
   parameters:<parameteres>
      success:^(AFHTTPRequestOperation *operation, id responseObject) {
          NSLog(@“Success: %@", responseObject);
      } failure:^(AFHTTPRequestOperation *operation, NSError *error) {
          NSLog(@"Error: %@", error);
      }];

Я пытался, NSURLSessionно все равно получаю ту же ошибку.

VoidStack
источник
Любое обновление? Это происходит только на iOS 8 на Wifi для меня, все еще пытаясь найти обходной путь.
Димиллиан
Может кто-нибудь помочь мне решить мою проблему, почти ту же проблему, но другой код ошибки, stackoverflow.com/questions/26972822/…
iYoung
1
столкнулся с той же проблемой с iOS 10.0.1 и Xcode 8.
Satheeshwaran
1
Сегодня утром я получил эту ошибку и исправил ее простым и странным решением. Запрошенный адрес сервера неверен, не возвращен код состояния 4xx или 5xx, он только что столкнулся с этой проблемой, не зная, что именно является основной причиной. Поэтому, пожалуйста, подтвердите это с бэкэнд-разработчиками в вашей команде, иначе вы потратите на это несколько часов.
Итачи

Ответы:

413

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

Collin
источник
3
Что будет, если эта проблема на устройстве, а не на симе? Пробовал перезагружать устройство, все та же ошибка.
Шон Кларк
2
@SeanClark: см. Следующий ответ: перезагрузка симулятора работает, потому что ОС должна сбросить мертвое соединение, а не пытаться повторно использовать их после того, как они были сброшены сервером. Чтобы обойти эту проблему, вы можете отключить механизм Keep-alive на сервере для клиентов iOS, или, если у вас нет доступа к серверу, вы можете просто повторить тот же запрос в случае сбоя (сбой должен сделать ОС сбрасывает соединение, и при отправке повторной попытки создается новое соединение).
Артур
Я в настоящее время использую Xcode 6.2, и что решило это, щелкнув по iOS Simulator> Сбросить настройки и контент. Как только это закончилось, я вышел из симулятора, перестроил и запустил свой проект ... потом все работало отлично.
KingPolygon
Я работал для сброса симулятора, но только в 10% случаев. Я только что получил нового провайдера, и он работает довольно странно. Это происходит все время сейчас на симуляторе. Может быть сеть.
noobsmcgoobs
1
Сброс симулятора не работал для меня. Однако старт Чарльза заставил проблему исчезнуть. См. Stackoverflow.com/a/26066764/598057, в котором предлагается использовать Чарльза. Очень странно, но работает ...
Станислав Панкевич
231

У нас была именно эта ошибка, и это оказалось проблемой с базовой реализацией HTTP NSURLRequest:

Насколько мы можем судить, когда iOS 8/9/10/11 получает ответ HTTP с Keep-Aliveзаголовком, она сохраняет это соединение для повторного использования позже (как и должно быть), но сохраняет его больше, чем timeoutпараметр Keep-Alive header (кажется, он всегда поддерживает соединение в течение 30 секунд.) Затем, когда приложение отправляет второй запрос менее чем через 30 секунд, оно пытается повторно использовать соединение, которое могло быть сброшено сервером (если прошло больше реального Keep-Alive).

Вот решения, которые мы нашли до сих пор:

  • Увеличьте параметр времени ожидания сервера выше 30 секунд. Похоже, что iOS всегда ведет себя так, как будто сервер будет держать соединение открытым в течение 30 секунд, независимо от значения, указанного в заголовке Keep-Alive. (Это можно сделать для Apache, установив KeepAliveTimeoutопцию.
  • Вы можете просто отключить механизм поддержки активности для клиентов iOS на основе User-Agent вашего приложения (например, для Apache: BrowserMatch "iOS 8\." nokeepaliveв файле мода setenvif.conf)
  • Если у вас нет доступа к серверу, вы можете попробовать отправить свои запросы с Connection: closeзаголовком: это скажет серверу немедленно прекратить соединение и ответить без заголовков поддержки активности. НО в настоящий момент NSURLSession, кажется, переопределяет Connectionзаголовок при отправке запросов (мы не тестировали это решение всесторонне, так как мы можем настроить конфигурацию Apache)
Артур
источник
7
Вот пример проекта, демонстрирующего проблему, отчет об ошибке также был отправлен в Apple. cl.ly/Xgkl/keep-alive-fail.zip Запустите проект, нажмите кнопку первого сообщения (вверху на экране), подождите 5 секунд, нажмите на него еще раз, ошибка.
Димиллиан
5
Поддержание жизни является двусторонним. Клиенты по умолчанию добавят http-заголовок «Connection: Keep-Alive», может помочь добавление параметров keep-alive в клиентские запросы; например, "Keep-Alive: max = 1". Комментарий Артура очень полезен, но также указывает на более чем одну проблему в сети симулятора iOS8. Я должен использовать https для получения соединения, так как http не удается перед отправкой запроса.
14:00
5
Эй, ребята, у меня точно такая же проблема на устройстве. можно ли это исправить? На iOS 7 проблем нет.
Андрес C
9
Совет: вы можете использовать NSURLErrorNetworkConnectionLostконстанту вместо жесткого кодирования -1005.
Винсент Туррэйн
6
Эта проблема все еще присутствует на iOS 11.2.6.
Makalele
47

По моему, Resetting content and settingsСимулятор работает. Для сброса симулятора выполните следующие действия:

Симулятор iOS -> Сбросить содержимое и настройки -> Нажмите Сброс (при появлении предупреждения)

Манаб Кумар Мал
источник
29

Во время выполнения симулятора iOS 8.0 имеется ошибка, из-за которой, если ваша сетевая конфигурация изменяется во время загрузки имитируемого устройства, высокоуровневые API (например, CFNetwork) в симулированной среде выполнения будут думать, что они потеряли сетевое соединение. В настоящее время рекомендуемый обходной путь - просто перезагрузить моделируемое устройство при изменении конфигурации сети.

Если вы столкнулись с этой проблемой, отправьте дополнительные дубликаты радаров по адресу http://bugreport.apple.com, чтобы повысить их приоритетность.

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

Джереми Хаддлстон Секвойя
источник
7
У меня есть эта проблема на устройстве тоже.
Даррен
@darren Тогда это не та проблема, о которой я говорил. Я предлагаю вам подать радар.
Джереми Хаддлстон Секвойя
4
пожалуйста, укажите ваш радарный идентификатор, чтобы упростить регистрацию дубликатов
Даниэль Галаско
11

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

m.eldehairy
источник
Это также помогает убить приложение перед сбросом симулятора и перезагрузить Mac. Я часто меняю места с разными точками доступа Wi-Fi, и это процедура, которая решает проблему для меня.
Владимир Славик,
11

Также есть проблема с бета 5 и AFNetworking 1.3 при работе на симуляторе iOS 8, которая приводит к ошибке соединения:

Domain = NSURLErrorDomain Code = -1005 "Сетевое соединение потеряно."

Тот же самый код прекрасно работает на симуляторах iOS 7 и 7.1, и мой прокси-сервер отладки показывает, что сбой происходит до того, как соединение действительно предпринято (т. Е. Запросы не регистрируются).

Я отследил сбой NSURLConnection и сообщил об ошибке в Apple. Смотрите строку 5 на прикрепленном изображении:

Клиентский делегат NSURLConnection не прошел ошибку,

Изменение использования httpsпозволяет подключаться к симуляторам iOS 8, хотя и с периодическими ошибками.

Проблема все еще присутствует в Xcode 6.01 (gm).

ПТКС
источник
Я вижу ту же проблему с NSURLSession и NSURLConnection, это исключает проблему с AFNetworking. Также я обнаружил, что он работает с https и не работает с http. Я все еще не мог найти никакого решения, у тебя было какое-нибудь решение?
VoidStack
Ни одно разрешение не сообщается, так как ошибка (18072300) добавит комментарий о работе https, который является хорошей информацией.
14:00
не могли бы вы вставить здесь ссылку на ошибку? Спасибо, потому что я думаю, что у меня та же проблема, но я использую только NSURLConnection (и делегаты), но я получаю то же сообщение об ошибке
szuniverse
Не удалось поделиться отчетом об ошибке Apple. Все еще открыт и по-прежнему присутствует в XCODE 6 beta 7. Если вы подаете отчет об ошибке, это также поможет с приоритетом.
ПТКС
Похоже, что эта проблема на симуляторе iOS, и я устал от реального устройства, оно работает нормально. Дальнейшая отладка Я обнаружил, что проблема связана с портом на симуляторе iOS, https порт 443 работает нормально, и я использовал 8080 для http, который раньше использовался для сбоя. Я попытался использовать другой порт (ы) и смог сделать http-вызов на симуляторе iOS. Похоже, ошибка в бета-версии Xcode 6, нужно дождаться стабильного Xcode 6.
VoidStack
10

Я испытывал эту проблему при использовании Alamofire. Моя ошибка состояла в том, что я отправлял пустой словарь [:]для параметров по GETзапросу, а не отправлял nilпараметры.

Надеюсь это поможет!

yujean
источник
GET и POST со словарем пустого тела [:] вызовут эту ошибку случайным образом. Я использую Python Flask для бэкэнд-API REST, это тоже может быть полезно.
Махмуд Файез
10

Открытие Чарльза решило проблему для меня, что кажется очень странным ...

Charles - это прокси-сервер HTTP / HTTP-монитор / обратный прокси-сервер, который позволяет разработчику просматривать весь трафик HTTP и SSL / HTTPS между их компьютером и Интернетом. Это включает в себя запросы, ответы и заголовки HTTP (которые содержат файлы cookie и информацию о кэшировании).

Колин Тремблэй
источник
1
Это тоже работает для меня, я думаю, потому что charles использует ssl-сертификат для прокси-сервера, который запрашивает сумматор, аналогично использованию https
thisispete
1
Это работает для меня каждый раз! Пробовал 30 раз, и он работает 30 из 30. Я думал, что это случайность, но приятно знать, что это не я.
JDOG
2
Charles - это прокси-инструмент, который позволяет вам наблюдать за трафиком с вашего компьютера. Проверьте charlesproxy.com для деталей. Сертификат Charles SSL может испортить способность симулятора выполнять сетевые запросы.
Колин Тремблей
@ColinTremblay Я думаю, что ваш симулятор / устройство настроено на использование прокси. Удаление прокси также будет работать.
bikram990
Смешно, это работало и для меня. Нужно было открыть Чарльза, а затем сбросить настройки симулятора iOS.
Мэтт Эндрюс
6

Смотрите комментарий pjebs 5 января на Github.

Метод 1:

if (error.code == -1005)
{
    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{

        dispatch_group_t downloadGroup = dispatch_group_create();
        dispatch_group_enter(downloadGroup);
        dispatch_group_wait(downloadGroup, dispatch_time(DISPATCH_TIME_NOW, 5000000000)); // Wait 5 seconds before trying again.
        dispatch_group_leave(downloadGroup);
        dispatch_async(dispatch_get_main_queue(), ^{
            //Main Queue stuff here
            [self redoRequest]; //Redo the function that made the Request.
        });
    });

    return;
}

Также некоторые предлагают повторно подключиться к сайту,

т.е. запускаем POST-запрос ДВАЖДЫ

Решение: Используйте метод для подключения к сайту, верните (id), если сетевое соединение было потеряно, вернитесь, чтобы использовать тот же метод.

Способ 2

-(id) connectionSitePost:(NSString *) postSender Url:(NSString *) URL {
     // here set NSMutableURLRequest =>  Request

    NSHTTPURLResponse *UrlResponse = nil;
    NSData *ResponseData = [[NSData alloc] init];

    ResponseData = [NSURLConnection sendSynchronousRequest:Request returningResponse:&UrlResponse error:&ErrorReturn];

     if ([UrlResponse statusCode] != 200) {

          if ([UrlResponse statusCode] == 0) {

                  /**** here re-use method ****/
                  return [self connectionSitePost: postSender Url: URL];
          }

     } else {
          return ResponseData;
     }

}
HDdeveloper
источник
Метод 1 очень мне помог. Спасибо
Абхишек Митра
4

Я тоже получал эту ошибку, но на реальных устройствах, а не на симуляторе. Мы заметили ошибку при доступе к нашей серверной части heroku по HTTPS (серверу gunicorn) и при выполнении ПОСТОВ с большими телами (что-нибудь более 64 КБ). Мы используем HTTP Basic Auth для аутентификации, и заметили, что ошибка была устранена, НЕ используя didReceiveChallenge:метод делегата в NSURLSession, а вместо этого вставляя аутентификацию в заголовок исходного запроса путем добавления Authentiation: Basic <Base64Encoded UserName:Password>. Это предотвращает необходимые 401, чтобы инициировать didReceiveChallenge:сообщение делегата, и последующее сетевое соединение потеряно.

rvijay007
источник
Большое спасибо за ваш ценный комментарий. Вы правы, если я загружу ниже 64 КБ строку base64 изображения, оно будет успешно загружено.
Винаяк Бхор
3

У меня была такая же проблема. Решение было простым, я установил HTTPBody, но не установлен HTTPMethodв POST. После исправления все было хорошо.

Тимур Берникович
источник
3

У меня такая же проблема. Я не знаю, как AFNetworking реализует запрос https, но причина для меня - проблема с кешем NSURLSession.

После отслеживания моего приложения из safari и последующей отправки запроса http появится сообщение «Ошибка загрузки http 1005». Если я перестану использовать "[NSURLSession sharedSession]", но использовать настраиваемый экземпляр NSURLSession для вызова метода «dataTaskWithRequest:», как указано ниже, проблема решена.

NSURLSessionConfiguration *config = [NSURLSessionConfiguration defaultSessionConfiguration];
config.requestCachePolicy = NSURLRequestReloadIgnoringLocalCacheData;
config.URLCache = nil;
self.session = [NSURLSession sessionWithConfiguration:config];

Просто не забудьте установить config.URLCache = nil;.

Цзя Сяо
источник
1
Я думаю, что все эти перезапускающие устройство / симулятор или сбрасывающие данные должны искать этот ответ. Мне кажется, что все их действия очищают кеш, который на самом деле решает проблему. Так что, вероятно, проблема с кэшем URL. Я собираюсь проверить это сейчас.
Камран Хан
2

Мне пришлось выйти из XCode, удалить содержимое папки DerivedData (~ / Library / Developer / Xcode / DerivedData или / Library / Developer / Xcode / DerivedData) и выйти из симулятора, чтобы сделать эту работу.

abinop
источник
1
Единственное соответствующее действие в этом списке - перезапуск симулятора. Перезапуск Xcode и удаление производных данных является чрезмерным.
Джереми Хаддлстон Секвойя
2

У меня также есть эта проблема, работающая на устройстве iOS 8. Это подробно описано здесь и похоже на случай, когда iOS пытается использовать соединения, для которых уже истекло время ожидания. Моя проблема не совпадает с проблемой Keep-Alive, описанной в этой ссылке, но, похоже, это тот же конечный результат.

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

Вот как я запускаю рекурсивный блок с AFNetworking: добавьте этот код в ваш файл класса соединения

// From Mike Ash's recursive block fixed-point-combinator strategy https://gist.github.com/1254684
dispatch_block_t recursiveBlockVehicle(void (^block)(dispatch_block_t recurse))
{
    // assuming ARC, so no explicit copy
    return ^{ block(recursiveBlockVehicle(block)); };
}
typedef void (^OneParameterBlock)(id parameter);
OneParameterBlock recursiveOneParameterBlockVehicle(void (^block)(OneParameterBlock recurse, id parameter))
{
    return ^(id parameter){ block(recursiveOneParameterBlockVehicle(block), parameter); };
}

Тогда используйте это как это:

+ (void)runOperationWithURLPath:(NSString *)urlPath
            andStringDataToSend:(NSString *)stringData
                    withTimeOut:(NSString *)timeOut
     completionBlockWithSuccess:(void (^)(AFHTTPRequestOperation *operation, id responseObject))success
                        failure:(void (^)(AFHTTPRequestOperation *operation, NSError *error))failure
{
    OneParameterBlock run = recursiveOneParameterBlockVehicle(^(OneParameterBlock recurse, id parameter) {
        // Put the request operation here that you want to keep trying
        NSNumber *offset = parameter;
        NSLog(@"--------------- Attempt number: %@ ---------------", offset);

        MyAFHTTPRequestOperation *operation =
            [[MyAFHTTPRequestOperation alloc] initWithURLPath:urlPath
            andStringDataToSend:stringData
            withTimeOut:timeOut];

        [operation setCompletionBlockWithSuccess:
            ^(AFHTTPRequestOperation *operation, id responseObject) {
                success(operation, responseObject);
            }
            failure:^(AFHTTPRequestOperation *operation2, NSError *error) {
                if (error.code == -1005) {
                    if (offset.intValue >= numberOfRetryAttempts) {
                        // Tried too many times, so fail
                        NSLog(@"Error during connection: %@",error.description);
                        failure(operation2, error);
                    } else {
                        // Failed because of an iOS bug using timed out connections, so try again
                        recurse(@(offset.intValue+1));
                    }
                } else {
                    NSLog(@"Error during connection: %@",error.description);
                    failure(operation2, error);
                }
            }];
        [[NSOperationQueue mainQueue] addOperation:operation];
    });
    run(@0);
}

Вы увидите, что я использую AFHTTPRequestOperationподкласс, но добавляю ваш собственный код запроса. Важной частью является вызов recurse(@offset.intValue+1));для повторного вызова блока.

Даррен
источник
Что такое класс MyAFHTTPRequestOperation?
JDog
Это просто подкласс AFHTTPRequestOperation. Я использую его для предопределения некоторых вещей, таких как тайм-аут и аутентификация.
Даррен
2

Если проблема возникает на устройстве, проверьте, проходит ли трафик через прокси (Настройки> Wi-Fi> (информация)> HTTP Proxy). У меня была настройка устройства для использования с Чарльзом, но я забыл про прокси. Кажется, что без Чарльза на самом деле работает эта ошибка происходит.

Дэвид Джеймс
источник
2

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

Raymond26
источник
2

Я получал ошибку на устройстве iOS 7, когда я использовал бета-версию Xcode 6.2.

Переход с бета-версии Xcode 6.2 на 6.1.1 исправил проблему, по крайней мере, на устройстве iOS 7.

Антон Тропашко
источник
Я не думаю, что есть что-то, чтобы решить: основная ОС разрывает соединение по причине, законной или нет. Приложение должно быть готово к работе с ним (работа в автономном режиме или что-то еще). Предполагая, что SDK в вашей конкретной версии xcode, конечно, не глючит: как показывает мой ответ, 6.2, скорее всего, глючит, а 6.1.1 - хорошо. Нечто подобное можно наблюдать сейчас, когда xcode 6.4 кажется достаточно стабильным, а 7.0.1 - это программное обеспечение альфа-класса. Или так кажется.
Антон Тропашко
2

На 2017-01-25Apple выпустили технический Q & A относительно этой ошибки:

Технические вопросы и ответы Apple QA1941

Обработка «Ошибка подключения к сети»

A: NSURLErrorNetworkConnectionLost - это ошибка -1005 в домене ошибок NSURLErrorDomain, которая отображается для пользователей как «Сетевое соединение было потеряно». Эта ошибка означает, что основное TCP-соединение, которое выполняет HTTP-запрос, отключено во время выполнения HTTP-запроса (дополнительную информацию об этом см. Ниже). В некоторых случаях NSURLSession может повторять такие запросы автоматически (в частности, если запрос идемпотентен), но в других случаях это не разрешено стандартами HTTP.

https://developer.apple.com/library/archive/qa/qa1941/_index.html#//apple_ref/doc/uid/DTS40017602

pkamb
источник
1

Получил проблему в течение нескольких месяцев, и, наконец, обнаружил, что когда мы отключаем DNSSEC на нашем домене API, все было в порядке: simple_smile:

Бриваэль Ле Погам
источник
2
Не могли бы вы уточнить?
Groot
1

Я подключался через VPN. Отключение VPN решило проблему.

alpere
источник
1

Я нажимал эту ошибку при передаче NSURLRequest в NSURLSession без установки HTTPMethod запроса .

NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:urlComponents.URL];

Ошибка Domain = NSURLErrorDomain Code = -1005 «Сетевое соединение потеряно».

Добавьте HTTPMethod, хотя, и соединение работает нормально

NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:urlComponents.URL];
[request setHTTPMethod:@"PUT"];
pkamb
источник
1

Проверьте, можете ли вы запросить у других приложений (например, Safari). Если нет, может быть что-то на вашем компьютере. В моем случае у меня была проблема с Avast Antivirus, который блокировал мой запрос на симуляторы (не спрашивайте меня, почему).

Привет Сой Эду Фелиз Навидад
источник
1

Перезагрузка компьютера исправила проблему для меня с Xcode9.1. Я перезапустил симулятор и Xcode, он не работает.

молодой
источник
1

Я столкнулся с той же проблемой, я включил Network Link Conditioner для медленного тестирования сети для приложения. Это создавало эту ошибку несколько раз, когда я ее отключил Settings > Developer > Network Link Conditioner, это решило мою проблему.

введите описание изображения здесь

Надеюсь, это поможет кому-то.

Давал Бхимани
источник
1

Вдобавок ко всем ответам я нашел одно хорошее решение. На самом деле проблема, связанная с ошибкой сетевого подключения для iOS 12.0, заключается в том, что в iOS 12.0 есть ошибка. И оно еще не решено. Я прошел через сообщество git hub для решения проблемы AFNetworking, когда приложение пришло из фона и пытается выполнить сетевой вызов и не может установить соединение. Я потратил 3 дня на это и пробовал много вещей, чтобы найти причину этого и ничего не нашел. Наконец я получил немного света в темноте, когда я красный этот блог https://github.com/AFNetworking/AFNetworking/issues/4279

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

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

Не ждите, пока Apple разрешит эту проблему для iOS 12, поскольку ее еще предстоит исправить. Вы можете использовать этот обходной путь, предоставив некоторую задержку для вашего сетевого запроса, являющегося его NSURLConnection, NSURLSession или AFNetworking или ALAMOFIRE. Ура :)

Шанкар осознает
источник
1

В моем случае это было потому, что я подключался к HTTP, и он работал по HTTPS.

Luky
источник
0

У меня была эта проблема по следующей причине.

TLDR: проверьте, отправляете ли вы GETзапрос, который должен отправлять параметры по URL, а не по NSURLRequest's HTTBodyсвойству.

==================================================

Я установил сетевую абстракцию в своем приложении, и она работала довольно хорошо для всех моих запросов.

Я добавил новый запрос в другой веб-сервис (не мой), и он начал выдавать мне эту ошибку.

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

В моей реализации абстракции была ошибка: я отправлял запрос, который должен был отправить параметры, закодированные в URL, и я также заполнял NSURLRequest's HTTBodyсвойство параметрами запроса. Как только я удалил, HTTPBodyвсе заработало.

Нуно Гонсалвеш
источник
0

Я получал эту ошибку, а также замечал, что приложение Почтальон тоже падало, но работало в приложении Advanced Rest Client (ARC) и работало в Android. Поэтому мне пришлось установить Чарльза для отладки связи, и я заметил, что код ответа был -1. Проблема была в том, что программист REST забыл вернуть код ответа 200.

Я надеюсь, что это поможет другим разработчикам.

Тиаго Мендес
источник
0

Всякий раз, когда появляется ошибка -1005, необходимо снова вызвать API.

AFHTTPRequestOperationManager *manager = 
[AFHTTPRequestOperationManager manager];
[manager setSecurityPolicy:policy];
manager.requestSerializer = [AFHTTPRequestSerializer serializer];
manager.responseSerializer = [AFHTTPResponseSerializer serializer];

[manager POST:<example-url>
   parameters:<parameteres>
    success:^(AFHTTPRequestOperation *operation, id responseObject) {
      NSLog(@“Success: %@", responseObject);
  } failure:^(AFHTTPRequestOperation *operation, NSError *error) {
      NSLog(@"Error: %@", error);
      if (error.code == -1005) {
          // Call method again... 
       }
  }];

Вам нужно добавить свой код, чтобы снова вызвать функцию. Убедитесь, что вы вызывали метод один раз, иначе вызовите рекурсивный цикл.

Piyush
источник
0

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

Я обнаружил ту же ошибку в другой ситуации, которую я считаю из-за тайм-аута, который нельзя параметризировать через стандартный сетевой API, предоставляемый Apple ( URLSession.timeoutIntervalForRequestи URLSession.timeoutIntervalForResource). Даже там .. заставил сервер ответить быстрее, решил проблему

Маттиа Персаджо Уно Дуччи
источник