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, NSURLSession
ale nadal pojawia się ten sam błąd.
ios8
ios-simulator
xcode6
xcode6-beta5
VoidStack
źródło
źródło
Odpowiedzi:
Ponowne uruchomienie symulatora rozwiązało problem.
źródło
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-Alive
nagłówkiem, zachowuje to połączenie do ponownego użycia później (tak jak powinno), ale zachowuje je dla więcej niżtimeout
parametru 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śliKeep-Alive
upłynęło więcej niż rzeczywiste ).Oto rozwiązania, które znaleźliśmy do tej pory:
KeepAliveTimeout
opcję.BrowserMatch "iOS 8\." nokeepalive
w pliku modsetenvif.conf
)Connection: close
nagłó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ćConnection
nagłówek, gdy żądania są wysyłane (nie testowaliśmy tego rozwiązania dokładnie, ponieważ możemy ulepszyć konfigurację Apache)źródło
NSURLErrorNetworkConnectionLost
stałej zamiast kodowania na stałe-1005
.Dla mnie,
Resetting content and settings
symulator działa. Aby zresetować symulator, wykonaj następujące czynności:źródło
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.
źródło
Rozwiązałem problem polegający na ponownym uruchomieniu symulatora oraz zresetowaniu zawartości i ustawień.
źródło
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:
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).
źródło
Wystąpił ten problem podczas używania Alamofire. Mój błąd polegał na tym, że wysyłałem pusty słownik
[:]
parametrów naGET
żądanie, a nie wysyłałemnil
parametry.Mam nadzieję że to pomoże!
źródło
Otwarcie Charlesa rozwiązało dla mnie problem, co wydaje się bardzo dziwne ...
źródło
Zobacz komentarz pjebs do 5 stycznia na Github.
Metoda 1:
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
źródło
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 dodanieAuthentiation: Basic <Base64Encoded UserName:Password>
. Zapobiega to niezbędnemu 401 do wyzwoleniadidReceiveChallenge:
komunikatu delegowanego i utraty połączenia sieciowego.źródło
Miałem ten sam problem. Rozwiązanie było proste, mam ustawione
HTTPBody
, ale nie jest ustawionaHTTPMethod
naPOST
. Po naprawieniu wszystko było w porządku.źródło
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.Pamiętaj tylko, aby ustawić
config.URLCache = nil;
.źródło
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.
źródł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
Następnie użyj tego lubi to:
Zobaczysz, że korzystam z
AFHTTPRequestOperation
podklasy, ale dodaj własny kod żądania. Ważną częścią jest wywołanie,recurse(@offset.intValue+1));
aby ponownie wywołać blok.źródło
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.
źródło
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.źródło
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.
źródło
Na
2017-01-25
Apple opublikował techniczne pytania i odpowiedzi dotyczące tego błędu:źródło
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:
źródło
Łączyłem się przez VPN. Wyłączenie VPN rozwiązało problem.
źródło
Trafiłem w ten błąd podczas przekazywania NSURLRequest do NSURLSession bez ustawiania metody HTTP żądania .
Dodaj
HTTPMethod
jednak, a połączenie działa poprawnieźródło
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).
źródło
Ponowne uruchomienie komputera rozwiązało problem z Xcode9.1. Uruchomiłem ponownie symulator i Xcode, to nie działa.
źródło
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.
źródło
W moim przypadku było tak, ponieważ łączyłem się z HTTP i działało na HTTPS
źródło
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 wNSURLRequest's HTTBody
wł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 HTTBody
właściwość parametrami zapytania. Jak tylko usunąłemHTTPBody
, zadziałało.źródł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.
źródło
Ilekroć pojawia się błąd -1005, należy ponownie wywołać API.
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.
źródło
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 :)
źródło
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.timeoutIntervalForRequest
iURLSession.timeoutIntervalForResource
). Nawet tam .. odpowiedź serwera szybciej rozwiązała problemźródło