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

У меня есть приложение, которое отлично работает на 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но все равно получаю ту же ошибку.

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

У нас была именно эта ошибка, и это оказалось проблемой с базовой реализацией 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)

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

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

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

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

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

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

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

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

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

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

,

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

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

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

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

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

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

Смотрите комментарий 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;
     }

}

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

У меня была такая же проблема. Решение было простым, я установил 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, и это в конечном итоге приводит к соединению, хотя иногда рекурсия может зацикливаться более 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));для повторного вызова блока.

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

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

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

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

На 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

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

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

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

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

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

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

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

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

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

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

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

Вдобавок ко всем ответам я нашел одно хорошее решение. На самом деле проблема, связанная с ошибкой сетевого подключения для 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. Ура :)

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

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

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

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

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

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

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

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

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

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

Всякий раз, когда появляется ошибка -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... 
       }
  }];

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

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

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