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

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

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

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

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

• Увеличьте время ожидания сервера выше 30 секунд. Похоже, что iOS всегда ведет себя так, как будто сервер будет поддерживать соединение открытым в течение 30 секунд независимо от значения, указанного в заголовке Keep-Alive. (Это можно сделать для Apache, установив параметр KeepAliveTimeout .
• Вы можете просто отключить механизм keep alive для клиентов iOS на основе User-Agent вашего приложения (например, для Apache: BrowserMatch "iOS 8\." nokeepalive в файле setenvif.conf )
• Если у вас нет доступа к серверу, вы можете попробовать отправить свои запросы с помощью заголовка Connection: close : это сообщит серверу о немедленном отключении подключения и ответе, не сохраняя заголовков. НО на данный момент NSURLSession, кажется, переопределяет заголовок Connection при отправке запросов (мы не тестировали это решение широко, поскольку мы можем настроить конфигурацию Apache)

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

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

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

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

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

Также возникают проблемы с бета-версией 5 и AFNetworking 1.3 при работе на симуляторе iOS8, что приводит к ошибке подключения «Domain = NSURLErrorDomain Code = -1005». Сетевое соединение было потеряно. ». Тот же самый код отлично работает на симуляторах iOS7 и 7.1, а прокси-сервер отладки показывает, что сбой происходит до того, как на самом деле было предпринято попытку подключения (т. Е. Никаких запросов не было зарегистрировано). Я проследил провал NSURLConnection и сообщил об ошибке Apple. См. Прилагаемую строку 5 в прикрепленном изображении. , Переход на использование https позволяет подключаться с iOS8-симуляторами, хотя и с прерывистыми ошибками. Проблема все еще присутствует в Xcode 6.01 (gm).

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

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

См. Комментарий 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 TWICE

Решение. Используйте метод для соединения с сайтом, return (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; } } 

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

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

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

У меня такая же проблема. Я не знаю, как 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; ,

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

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

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

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

 // 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); } 

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

Я получал ошибку даже на устройстве ios7, когда я использовал бета-версию xcode 6.2. переключение с xcode 6.2 beta на 6.1.1 исправило проблему. по крайней мере, на устройстве ios7.

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

Я тоже получал эту ошибку, но на реальных устройствах, а не на симуляторе. Мы заметили ошибку при доступе к нашему серверу heroku на HTTPS (сервер gunicorn) и сделали POSTS с большими bodys (что-то более 64Kb). Мы используем HTTP Basic Auth для аутентификации и заметили, что ошибка была решена НЕ используя метод didReceiveChallenge: delegate на NSURLSession, а скорее выпекаем в аутентификации в исходный заголовок запроса, добавив Authentiation: Basic . Это предотвращает необходимость 401 для запуска сообщения didReceiveChallenge: delegate и последующего сетевого соединения.

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

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

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

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

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

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

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

 NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:urlComponents.URL]; [request setHTTPMethod:@"PUT"]; 

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

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

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

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

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

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

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

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

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

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

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

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

 AFHTTPRequestOperationManager *manager = [AFHTTPRequestOperationManager manager]; [manager setSecurityPolicy:policy]; manager.requestSerializer = [AFHTTPRequestSerializer serializer]; manager.responseSerializer = [AFHTTPResponseSerializer serializer]; [manager POST: parameters: success:^(AFHTTPRequestOperation *operation, id responseObject) { NSLog(@“Success: %@", responseObject); } failure:^(AFHTTPRequestOperation *operation, NSError *error) { NSLog(@"Error: %@", error); if (error.code == -1005) { // Call method again... } }]; 

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

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

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