Error Domain = NSURLErrorDomain Code = -1005 „Połączenie sieciowe zostało utracone.”

Mam aplikację, która działa dobrze na Xcode6-Beta1 i Xcode6-Beta2 z iOS7 i iOS8. Ale z Xcode6-Beta3, Beta4, Beta5 mam problemy z siecią z iOS8, ale wszystko działa dobrze na iOS7. Dostaję błąd "The network connection was lost.". Błąd jest następujący:

Błąd: Błąd Domena = NSURLErrorDomain Code = -1005 „Połączenie sieciowe zostało utracone.” UserInfo = 0x7ba8e5b0 {NSErrorFailingURLStringKey =, _kCFStreamErrorCodeKey = 57, NSErrorFailingURLKey =, NSLocalizedDescription = Połączenie sieciowe zostało utracone., _KCFStreamErrorDomainKey = 1, NS7 Błąd 7 = Błąd 0x0

Używam AFNetworking 2.x i następującego fragmentu kodu, aby wykonać połączenie sieciowe:

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

Próbowałem, NSURLSessionale nadal pojawia się ten sam błąd.

Ponowne uruchomienie symulatora rozwiązało problem.

Wystąpił ten dokładny błąd i okazało się, że jest to problem z podstawową implementacją HTTP NSURLRequest:

O ile nam wiadomo, kiedy iOS 8/9/10/11 odbiera odpowiedź HTTP z Keep-Alivenagłówkiem, zachowuje to połączenie do ponownego użycia później (tak jak powinno), ale zachowuje je dla więcej niż timeoutparametru Keep-Alive header (wydaje się, że zawsze utrzymuje połączenie przy życiu przez 30 sekund.) Następnie, gdy aplikacja wysyła drugie żądanie mniej niż 30 sekund później, próbuje ponownie użyć połączenia, które mogło zostać zerwane przez serwer (jeśli Keep-Aliveupłynęło więcej niż rzeczywiste ).

Oto rozwiązania, które znaleźliśmy do tej pory:

• Zwiększ parametr limitu czasu serwera powyżej 30 sekund. Wygląda na to, że iOS zawsze zachowuje się tak, jakby serwer utrzymywał połączenie otwarte przez 30 sekund, niezależnie od wartości podanej w nagłówku Keep-Alive. (Można to zrobić dla Apache, ustawiając tę KeepAliveTimeoutopcję.
• Możesz po prostu wyłączyć mechanizm utrzymywania aktywności dla klientów iOS w oparciu o User-Agent Twojej aplikacji (np. Dla Apache: BrowserMatch "iOS 8\." nokeepalivew pliku mod setenvif.conf)
• Jeśli nie masz dostępu do serwera, możesz spróbować wysłać swoje żądania z Connection: closenagłówkiem: to powie serwerowi, aby natychmiast porzucił połączenie i odpowiedział bez żadnych nagłówków. ALE w tej chwili NSURLSession wydaje się przesłonić Connectionnagłówek, gdy żądania są wysyłane (nie testowaliśmy tego rozwiązania dokładnie, ponieważ możemy ulepszyć konfigurację Apache)

Dla mnie, Resetting content and settingssymulator działa. Aby zresetować symulator, wykonaj następujące czynności:

Symulator iOS -> Resetuj zawartość i ustawienia -> Naciśnij Resetuj (po wyświetlonym ostrzeżeniu)

W środowisku uruchomieniowym symulatora iOS 8.0 występuje błąd, przez który jeśli konfiguracja sieci ulegnie zmianie podczas uruchamiania symulowanego urządzenia, interfejsy API wyższego poziomu (np. CFNetwork) w symulowanym środowisku wykonawczym będą myśleć, że utraciły połączenie sieciowe. Obecnie zaleca się po prostu zrestartowanie symulowanego urządzenia po zmianie konfiguracji sieci.

Jeśli ten problem dotyczy Ciebie, zgłoś dodatkowe duplikaty radarów na stronie http://bugreport.apple.com, aby uzyskać wyższy priorytet.

Jeśli widzisz ten problem bez zmiany konfiguracji sieci, oznacza to, że nie jest to znany błąd i zdecydowanie powinieneś zgłosić radar, wskazujący, że problem nie jest znanym błędem po zmianie konfiguracji sieci.

Rozwiązałem problem polegający na ponownym uruchomieniu symulatora oraz zresetowaniu zawartości i ustawień.

Występuje również problem z wersją beta 5 i AFNetworking 1.3 podczas uruchamiania na symulatorze iOS 8, który powoduje błąd połączenia:

Domena = NSURLErrorDomain Code = -1005 „Połączenie sieciowe zostało utracone.”

Ten sam kod działa poprawnie na symulatorach iOS 7 i 7.1, a mój serwer proxy debugowania pokazuje, że awaria występuje przed próbą nawiązania połączenia (tzn. Nie są rejestrowane żadne żądania).

Śledziłem awarię NSURLConnection i zgłaszałem błąd do Apple. Zobacz wiersz 5 na załączonym obrazku:

.

Zmiana w użyciu https umożliwia połączenie z symulatorów iOS 8, choć występują sporadyczne błędy.

Problem nadal występuje w Xcode 6.01 (gm).

Wystąpił ten problem podczas używania Alamofire. Mój błąd polegał na tym, że wysyłałem pusty słownik [:]parametrów na GETżądanie, a nie wysyłałemnil parametry.

Mam nadzieję że to pomoże!

Otwarcie Charlesa rozwiązało dla mnie problem, co wydaje się bardzo dziwne ...

Charles to serwer proxy HTTP / monitor HTTP / zwrotny serwer proxy, który umożliwia programistom przeglądanie całego ruchu HTTP i SSL / HTTPS między komputerem a Internetem. Obejmuje to żądania, odpowiedzi i nagłówki HTTP (które zawierają pliki cookie i informacje o buforowaniu).

Zobacz komentarz pjebs do 5 stycznia na Github.

Metoda 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;
}

Również niektóre sugerują ponowne połączenie z witryną,

tj. dwa razy uruchomienie żądania POST

Rozwiązanie: Użyj metody, aby nawiązać połączenie z witryną, zwróć (id), jeśli połączenie sieciowe zostało utracone, wróć, aby użyć tej samej metody.

Metoda 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;
     }

}

Ten błąd również występował, ale na rzeczywistych urządzeniach, a nie na symulatorze. Zauważyliśmy błąd podczas uzyskiwania dostępu do naszego zaplecza heroku na HTTPS (serwer gunicorn) i wykonywania POSTS z dużymi ciałami (cokolwiek powyżej 64Kb). Używamy uwierzytelniania podstawowego HTTP do uwierzytelnienia i zauważyliśmy, że błąd został rozwiązany NIE przez użycie didReceiveChallenge:metody delegowania na sesji NSURLSession, ale raczej poprzez wypalenie uwierzytelnienia w oryginalnym nagłówku żądania poprzez dodanie Authentiation: Basic <Base64Encoded UserName:Password>. Zapobiega to niezbędnemu 401 do wyzwolenia didReceiveChallenge:komunikatu delegowanego i utraty połączenia sieciowego.

Miałem ten sam problem. Rozwiązanie było proste, mam ustawione HTTPBody, ale nie jest ustawiona HTTPMethodna POST. Po naprawieniu wszystko było w porządku.

Miałem ten sam problem. Nie wiem, jak AFNetworking implementuje żądanie https, ale moim powodem jest problem pamięci podręcznej NSURLSession.

Po tym, jak moja aplikacja wyśledzi z safari, a następnie opublikuje żądanie HTTP, pojawi się błąd „HTTP load failed 1005”. Jeśli przestanę używać "[NSURLSession sharedSession]", ale aby użyć konfigurowalnej instancji NSURLSession w celu wywołania metody „dataTaskWithRequest:” w następujący sposób, problem zostanie rozwiązany.

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

Pamiętaj tylko, aby ustawić config.URLCache = nil;.

Musiałem wyjść z XCode, usunąć zawartość folderu DerivedData (~ / Library / Developer / Xcode / DerivedData lub / Library / Developer / Xcode / DerivedData) i wyjść z symulatora, aby to zadziałało.

Mam ten problem również na urządzeniu z systemem iOS 8. Jest on bardziej szczegółowy tutaj i wydaje się, że jest to przypadek, gdy iOS próbuje użyć połączeń, które już upłynęły limit czasu. Mój problem nie jest taki sam jak problem Keep-Alive wyjaśniony w tym linku, jednak wydaje się, że jest to ten sam efekt końcowy.

Rozwiązałem problem, uruchamiając blok rekurencyjny za każdym razem, gdy pojawia się błąd -1005, co powoduje, że połączenie ostatecznie się przebija, nawet jeśli czasami rekurencja może zapętlać się ponad 100 razy, zanim połączenie zadziała, jednak dodaje tylko sekundę do uruchomienia razy i założę się, że jest to czas, w którym debuger drukuje dla mnie NSLog.

Oto jak uruchamiam blok rekurencyjny za pomocą AFNetworking: Dodaj ten kod do pliku klasy połączenia

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

Następnie użyj tego lubi to:

+ (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);
}

Zobaczysz, że korzystam z AFHTTPRequestOperationpodklasy, ale dodaj własny kod żądania. Ważną częścią jest wywołanie, recurse(@offset.intValue+1));aby ponownie wywołać blok.

Jeśli problem występuje na urządzeniu, sprawdź, czy ruch przechodzi przez serwer proxy (Ustawienia> Wi-Fi> (informacje)> Serwer proxy HTTP). Miałem konfigurację urządzenia do pracy z Charlesem, ale zapomniałem o proxy. Wydaje się, że bez Charles faktycznie działa ten błąd występuje.

Jeśli ktoś otrzymuje ten błąd podczas przesyłania plików na serwer zaplecza, upewnij się, że serwer odbierający ma maksymalny rozmiar zawartości, który jest dozwolony dla Twojego nośnika. W moim przypadku NGINX wymagał wyższej client_max_body_size. NGINX odrzuci żądanie przed zakończeniem przesyłania, więc kod błędu nie powróci.

Podczas używania Xcode 6.2 beta pojawiał się błąd na urządzeniu z systemem iOS 7.

Powrót z Xcode 6.2 beta do 6.1.1 naprawił problem, przynajmniej na urządzeniu z iOS 7.

Na 2017-01-25Apple opublikował techniczne pytania i odpowiedzi dotyczące tego błędu:

Techniczne pytania i odpowiedzi Apple QA1941

Obsługa błędów „Utracono połączenie sieciowe” Błędy

Odp .: NSURLErrorNetworkConnectionLost ma błąd -1005 w domenie błędów NSURLErrorDomain i jest wyświetlany użytkownikom jako „Utracono połączenie sieciowe”. Ten błąd oznacza, że ​​podstawowe połączenie TCP, które przenosi żądanie HTTP, zostało rozłączone podczas trwania żądania HTTP (więcej informacji na ten temat znajduje się poniżej). W niektórych okolicznościach NSURLSession może ponawiać takie żądania automatycznie (szczególnie jeśli żądanie jest idempotentne), ale w innych okolicznościach nie jest to dozwolone przez standardy HTTP.

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

Dostrzegaliśmy problem od miesięcy i wreszcie odkryliśmy, że kiedy wyłączamy DNSSEC w naszej domenie API, wszystko było w porządku: simple_smile:

Łączyłem się przez VPN. Wyłączenie VPN rozwiązało problem.

Trafiłem w ten błąd podczas przekazywania NSURLRequest do NSURLSession bez ustawiania metody HTTP żądania .

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

Error Domain = NSURLErrorDomain Code = -1005 „Połączenie sieciowe zostało utracone.”

Dodaj HTTPMethodjednak, a połączenie działa poprawnie

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

Sprawdź, czy możesz poprosić o to z innych aplikacji (np. Safari). Jeśli nie, może być coś na twoim komputerze. W moim przypadku miałem ten problem z programem Avast Antivirus, który blokował moje żądanie symulatorów (nie pytaj mnie dlaczego).

Ponowne uruchomienie komputera rozwiązało problem z Xcode9.1. Uruchomiłem ponownie symulator i Xcode, to nie działa.

Miałem do czynienia z tym samym problemem, włączyłem Network Link Conditioner do powolnego testowania sieci dla aplikacji. To powodowało błąd czasami, kiedy go wyłączyłem Settings > Developer > Network Link Conditioner, rozwiązało to mój problem.

Mam nadzieję, że komuś to pomoże.

W moim przypadku było tak, ponieważ łączyłem się z HTTP i działało na HTTPS

Miałem ten problem z następującego powodu.

TLDR: Sprawdź, czy wysyłasz GETżądanie, które powinno przesyłać parametry w adresie URL zamiast w NSURLRequest's HTTBodywłaściwości.

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

W aplikacji zainstalowałem abstrakcję sieci i działała całkiem dobrze w przypadku wszystkich moich próśb.

Dodałem nowe żądanie do innej usługi sieci Web (innej niż moja) i zaczęło mi to generować ten błąd.

Poszedłem na plac zabaw i zacząłem od podstaw, budując prośbę od podstaw, i zadziałało. Zacząłem więc przybliżać się do mojej abstrakcji, dopóki nie znalazłem przyczyny.

W mojej implementacji abstrakcji wystąpił błąd: wysyłałem żądanie, które miało wysłać parametry zakodowane w adresie URL, a także wypełniałem NSURLRequest's HTTBodywłaściwość parametrami zapytania. Jak tylko usunąłem HTTPBody, zadziałało.

Otrzymałem ten błąd, a także zauważyłem, że aplikacja Postman również spadała, ale pracowała w aplikacji Advanced Rest Client (ARC) i działała na Androidzie. Musiałem więc zainstalować Charlesa do debugowania komunikacji i zauważyłem, że kod odpowiedzi wynosił -1. Problem polegał na tym, że programista REST zapomniał zwrócić kod odpowiedzi 200.

Mam nadzieję, że pomoże to innym programistom.

Ilekroć pojawia się błąd -1005, należy ponownie wywołać 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... 
       }
  }];

Musisz ponownie dodać kod, aby wywołać funkcję ponownie. Upewnij się, że byłeś kiedyś metodą wywołania, w przeciwnym razie jej pętla rekurencyjna.

Oprócz wszystkich odpowiedzi znalazłem jedno fajne rozwiązanie. W rzeczywistości problem związany z niepowodzeniem połączenia sieciowego dla słowa systemu iOS 12 jest spowodowany błędem w słowie systemu iOS 12.0. I to jeszcze nie rozwiązane. Przeszedłem przez społeczność git hub dla problemu związanego z siecią AFNetworking, gdy aplikacja pochodzi z tła i próbuje nawiązać połączenie sieciowe i nie udaje się nawiązać połączenia. Spędzam na tym 3 dni i próbuję wielu rzeczy, aby dotrzeć do pierwotnej przyczyny tego i nic nie znalazłem. W końcu mam trochę światła w ciemności, kiedy redaguję tego bloga https://github.com/AFNetworking/AFNetworking/issues/4279

Mówi, że w iOS 12. jest błąd. Zasadniczo nie można oczekiwać, że połączenie sieciowe zostanie zakończone, jeśli aplikacja nie będzie na pierwszym planie. Z powodu tego błędu połączenia sieciowe są przerywane, aw dziennikach pojawia się awaria sieci.

Moją najlepszą sugestią jest opóźnienie, gdy aplikacja przechodzi z tła na pierwszy plan i występuje połączenie sieciowe. Wykonaj asynchroniczne połączenie sieciowe w wysyłce z pewnym opóźnieniem. Nigdy nie dostaniesz połączenia sieciowego ani utraty połączenia.

Nie czekaj, aż Apple pozwoli rozwiązać ten problem w systemie iOS 12, ponieważ wciąż nie został rozwiązany. Możesz obejść to obejście, zapewniając pewne opóźnienie dla żądania sieciowego, jakim jest jego NSURLConnection, NSURLSession lub AFNetworking lub ALAMOFIRE. Twoje zdrowie :)

Ten sam problem napotkałem podczas rozmowy za pomocą serwera mojej firmy z aplikacji iOS 12 na urządzeniu fizycznym. Problem polegał na tym, że dysk twardy serwera był pełny. Zwolnienie miejsca na serwerze rozwiązało problem.

Znalazłem ten sam błąd w innej sytuacji, myślę, że z powodu przekroczenia limitu czasu, którego nie można sparametryzować za pomocą standardowego interfejsu API sieci dostarczonego przez Apple ( URLSession.timeoutIntervalForRequesti URLSession.timeoutIntervalForResource). Nawet tam .. odpowiedź serwera szybciej rozwiązała problem