Домен помилки = NSURLErrorDomain Code = -1005 "Мережеве з'єднання було втрачено."

У мене є додаток, який добре працює на Xcode6-Beta1 і Xcode6-Beta2 з обома iOS7 та iOS8. Але з Xcode6-Beta3, Beta4, Beta5 я стикаюся з мережевими проблемами з iOS8, але в iOS7 все працює добре. Я отримую помилку "The network connection was lost.". Помилка така:

Помилка: Домен помилки = NSURLErrorDomain Code = -1005 "Мережеве з'єднання було втрачено." UserInfo = 0x7ba8e5b0 {NSErrorFailingURLStringKey =, _kCFStreamErrorCodeKey = 57, NSErrorFailingURLKey =, NSLocalizedDescription = Мережне з'єднання було втрачено.

Я використовую 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 (він, здається, завжди підтримує зв’язок живим протягом 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 settingsSimulator працює. Щоб скинути тренажер, виконайте наступні дії:

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

У режимі роботи симулятора iOS 8.0 є помилка, через яку ваші мережеві конфігурації змінюються під час завантаження модельованого пристрою, API більш високого рівня (наприклад, CFNetwork) під час імітації буде думати, що він втратив мережевий зв’язок. Наразі радимо вирішити проблему просто перезавантажити модельований пристрій, коли ваша мережна конфігурація зміниться.

Якщо вас зачепить ця проблема, будь ласка, подайте додаткові дублікати радарів на http://bugreport.apple.com, щоб підвищити пріоритетність.

Якщо ви бачите цю проблему, не змінюючи конфігурації мережі, то це не відома помилка, і ви обов'язково повинні подати радар, вказуючи, що проблема не є відомою помилкою, зміненою конфігурацією мережі.

що вирішило проблему для мене - перезапустити тренажер та скинути вміст та налаштування.

Також виникають проблеми з бета-версією 5 та AFNetworking 1.3 під час роботи на тренажері iOS 8, що призводить до помилки підключення:

Домен = NSURLErrorDomain Code = -1005 "Мережеве з'єднання було втрачено."

Цей же код добре працює на тренажерах iOS 7 та 7.1, і мій проксі-налагоджувальний проксі показує, що збій виникає до того, як насправді буде здійснено спробу з'єднання (тобто не записуються запити).

Я відслідковував провал NSURLConnection і повідомив про помилку в Apple. Дивіться рядок 5 на доданому зображенні:

.

Перехід до використання httpsдозволяє підключатись до тренажерів iOS 8, хоча і з періодичними помилками.

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

У мене виникла ця проблема під час використання Alamofire. Моя помилка полягала в тому, що я надсилав порожній словник [:]для параметрів за GETзапитом, а не надсилав nilпараметри.

Сподіваюсь, це допомагає!

Відкриття Чарльза вирішило проблему для мене, що здається дуже дивним ...

Чарльз - це HTTP-проксі / HTTP-монітор / Зворотний проксі, який дозволяє розробнику переглядати весь трафік HTTP та SSL / HTTPS між їх машиною та Інтернетом. Сюди входять запити, відповіді та заголовки HTTP (які містять файли cookie та кешування).

Дивіться коментар пебса 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 ДВА

Рішення: Використовуйте метод для підключення до сайту, 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;
     }

}

Я також отримував цю помилку, але на фактичних пристроях, а не на тренажері. Ми помітили помилку, коли отримували доступ до нашого резервного файлу heroku на HTTPS (сервер гуманікорну) та виконували POSTS з великими кузовами (що-небудь понад 64 Кб). Ми використовуємо HTTP Basic Auth для аутентифікації, і помітили, що помилка була didReceiveChallenge:усунена НЕ за допомогою методу делегування в NSURLSession, а скоріше випікання під час автентифікації в оригінальний заголовок запиту шляхом додавання Authentiation: Basic <Base64Encoded UserName:Password>. Це запобігає необхідності 401 для запуску didReceiveChallenge:повідомлення про делегат, а подальше втрата мережевого з'єднання втрачається.

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

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

Після мого відстеження програми із сафарі та після публікації 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 (~ / Бібліотека / Розробник / Xcode / DerivedData або / Бібліотека / Розробник / 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-проксі). Я мав налаштування свого пристрою для використання з Чарльзом, але забув про проксі. Здається, що без Чарльза насправді ця помилка виникає.

Якщо хтось отримує цю помилку під час завантаження файлів на бекенд-сервер, переконайтеся, що приймаючий сервер має максимальний розмір вмісту, дозволений для вашого медіа. У моєму випадку NGINX вимагав більш високу client_max_body_size. NGINX відхилить запит перед завантаженням, тому код помилки не повернувся.

Я отримував помилку на пристрої iOS 7, коли використовував бета-версію Xcode 6.2.

Перемикання з Xcode 6.2 beta на 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];

Домен помилки = NSURLErrorDomain Code = -1005 "Мережеве з'єднання було втрачено."

Додайте HTTPMethod, хоча, і з'єднання справно працює

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

Перевірте, чи можете ви запитувати інші програми (наприклад, сафарі). Якщо це не може бути щось на вашому комп'ютері. У моєму випадку у мене виникла ця проблема з Avast Antivirus, який блокував мій запит тренажерів (не питайте мене чому).

Перезавантаження комп'ютера вирішило проблему для мене з Xcode9.1. Я перезапустив тренажер і Xcode, він не працює.

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

Сподіваюся, це допоможе комусь.

У моєму випадку це було тому, що я підключався до HTTP і він працював на HTTPS

У мене виникло це питання з наступної причини.

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

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

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

Я додав новий запит до іншої веб-служби (не моєї власної), і вона почала кидати мені цю помилку.

Я пішов на майданчик і почав з нуля будувати запит на босоніжки, і це спрацювало. Тому я почав ближче до своєї абстракції, поки не знайшов причину.

Моя реалізація абстракції мала помилку: я надсилав запит, який повинен був надіслати параметри, закодовані в URL-адресі, і я також заповнював NSURLRequest's HTTBodyвластивість параметрами запиту. Як тільки я його зняв, HTTPBodyце спрацювало.

Я отримував цю помилку, а також помічав, що програма Postman також падає, але працює в додатку 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 onword, тому що в iOS 12.0 є помилка. І це все-таки вирішено. Я пройшов спільноту git hub для проблеми, пов’язаної з AFNetworking, коли додаток з’явився з фонового режиму і намагається здійснити мережевий дзвінок і не вдалося встановити з'єднання. Я витрачаю на це 3 дні і намагаюся багато речей дістати до першопричини цього і нічого не знайшов. Нарешті я отримав трохи світла в темряві, коли я червоно читав цей блог https://github.com/AFNetworking/AFNetworking/isissue/4279

Це говорить про те, що в iOS 12. є помилка. В основному, ви не можете очікувати, що мережевий дзвінок буде завершений, якщо програма не на передньому плані. І через цю помилку мережеві дзвінки падають, і ми отримуємо помилки мережі в журналах.

Моя найкраща пропозиція для вас - надати деяку затримку, коли ваш додаток переходить із фону на другий план і відбувається дзвінок у мережі. Здійсніть цей мережевий дзвінок у диспетчерській асинхронізації з деякою затримкою. Ви ніколи не отримаєте падіння мережевих дзвінків або втрату з’єднання.

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

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

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