Fehlerdomäne = NSURLErrorDomain Code = -1005 "Die Netzwerkverbindung wurde unterbrochen."


268

Ich habe eine Anwendung, die auf Xcode6-Beta1 und Xcode6-Beta2 mit iOS7 und iOS8 gut funktioniert. Aber mit Xcode6-Beta3, Beta4, Beta5 habe ich Netzwerkprobleme mit iOS8, aber unter iOS7 funktioniert alles einwandfrei. Ich bekomme den Fehler "The network connection was lost.". Der Fehler ist wie folgt:

Fehler: Fehler Domain = NSURLErrorDomain Code = -1005 "Die Netzwerkverbindung wurde unterbrochen." UserInfo = 0x7ba8e5b0 {NSErrorFailingURLStringKey =, _kCFStreamErrorCodeKey = 57, NSErrorFailingURLKey =, NSLocalizedDescription = Die Netzwerkverbindung wurde unterbrochen., _KCFStreamErrorDomainKey = 1, NSUnderx7 "

Ich verwende AFNetworking 2.x und das folgende Codefragment, um den Netzwerkanruf zu tätigen:

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

Ich habe versucht, NSURLSessionaber immer noch den gleichen Fehler erhalten.


Irgendein Update ? Es passiert für mich nur unter iOS 8 über Wifi und versucht immer noch, eine Problemumgehung zu finden.
Dimillian


Kann mir jemand helfen, mein Problem zu lösen, fast das gleiche Problem, aber unterschiedlicher Fehlercode, stackoverflow.com/questions/26972822/…
iYoung

1
vor dem gleichen Problem mit iOS 10.0.1 und Xcode 8.
Satheeshwaran

1
Ich habe diesen Fehler heute Morgen erhalten und ihn gerade mit einer einfachen und seltsamen Lösung behoben. Die angeforderte Serveradresse ist falsch. Es wird kein 4xx- oder 5xx-Statuscode zurückgegeben. Es ist nur dieses Problem aufgetreten, nicht sicher, was genau die Hauptursache ist. Bitte bestätigen Sie dies mit den Backend-Entwicklern in Ihrem Team, sonst verschwenden Sie ein paar Stunden damit.
Itachi

Antworten:


414

Durch einen Neustart des Simulators wurde das Problem für mich behoben.


3
Was passiert, wenn dieses Problem auf dem Gerät und nicht auf der Sim liegt? Versucht, das Gerät neu zu starten, immer noch der gleiche Fehler.
Sean Clark

2
@ SeanClark: Siehe die nächste Antwort: Der Neustart des Simulators funktioniert, da das Betriebssystem die tote Verbindung trennen muss, anstatt zu versuchen, sie wiederzuverwenden, nachdem sie vom Server gelöscht wurden. Um dieses Problem zu umgehen, können Sie den Keep-Alive-Mechanismus auf dem Server für die iOS-Clients deaktivieren. Wenn Sie keinen Zugriff auf den Server haben, können Sie dieselbe Anforderung einfach erneut versuchen, wenn sie fehlschlägt (Fehler sollte auftreten Das Betriebssystem trennt die Verbindung und eine neue wird instanziiert, wenn der Wiederholungsversuch gesendet wird.
Arthur

Ich verwende derzeit Xcode 6.2 und habe das Problem gelöst, indem ich auf iOS Simulator> Einstellungen und Inhalt zurücksetzen geklickt habe. Sobald das erledigt war, verließ ich den Simulator und baute mein Projekt neu auf und führte es aus ... danach funktionierte alles perfekt.
KingPolygon

Es hat bei mir funktioniert, den Simulator zurückzusetzen, aber nur 10% der Zeit. Ich habe gerade einen neuen ISP bekommen und es läuft irgendwie komisch. Dies geschieht jetzt die ganze Zeit im Simulator. Könnte das Netzwerk sein.
Noobsmcgoobs

1
Das Zurücksetzen des Simulators hat bei mir nicht funktioniert. Der Start von Charles ließ das Problem jedoch verschwinden. Siehe stackoverflow.com/a/26066764/598057, in dem die Verwendung von Charles vorgeschlagen wird. Sehr seltsam, funktioniert aber ...
Stanislav Pankevich

231

Wir hatten genau diesen Fehler und es stellte sich heraus, dass es ein Problem mit der zugrunde liegenden HTTP-Implementierung von NSURLRequest:

Soweit wir wissen Keep-Alive, behält iOS 8/9/10/11, wenn es eine HTTP-Antwort mit einem Header empfängt , diese Verbindung bei, um sie später wiederzuverwenden (wie es sollte), aber es behält sie für mehr als den timeoutParameter des Keep-Alive-Header (die Verbindung scheint immer 30 Sekunden lang am Leben zu bleiben.) Wenn die App weniger als 30 Sekunden später eine zweite Anforderung sendet, versucht sie, eine vom Server möglicherweise unterbrochene Verbindung wiederzuverwenden (wenn mehr als das Reale Keep-Alivevergangen ist).

Hier sind die Lösungen, die wir bisher gefunden haben:

  • Erhöhen Sie den Timeout-Parameter des Servers auf über 30 Sekunden. Es sieht so aus, als würde sich iOS immer so verhalten, als würde der Server die Verbindung 30 Sekunden lang offen halten, unabhängig vom Wert, der im Keep-Alive-Header angegeben ist. (Dies kann für Apache durch Festlegen der KeepAliveTimeoutOption erfolgen.
  • Sie können den Keep-Alive-Mechanismus für iOS-Clients basierend auf dem User-Agent Ihrer App einfach deaktivieren (z. B. für Apache: BrowserMatch "iOS 8\." nokeepalivein der Mod-Datei setenvif.conf).
  • Wenn Sie keinen Zugriff auf den Server haben, können Sie versuchen, Ihre Anforderungen mit einem Connection: closeHeader zu senden. Dadurch wird der Server angewiesen, die Verbindung sofort zu trennen und ohne Keep-Alive-Header zu antworten. ABER im Moment scheint NSURLSession den ConnectionHeader zu überschreiben, wenn die Anforderungen gesendet werden (wir haben diese Lösung nicht ausführlich getestet, da wir die Apache-Konfiguration optimieren können).

7
Hier ist ein Beispielprojekt, das das Problem demonstriert. Ein Fehlerbericht wurde auch an Apple gesendet. cl.ly/Xgkl/keep-alive-fail.zip Starten Sie das Projekt, klicken Sie auf die Schaltfläche für den ersten Beitrag (oben auf dem Bildschirm), warten Sie 5 Sekunden, klicken Sie erneut darauf, Fehler.
Dimillian

5
Keep-Alive ist bilateral. Clients fügen standardmäßig einen http-Header "Connection: Keep-Alive" hinzu. Das Hinzufügen von Keep-Alive-Parametern zu den Client-Anforderungen kann hilfreich sein. zB "Keep-Alive: max = 1". Arthurs Kommentar ist sehr hilfreich, weist aber auch auf mehr als ein Problem im iOS8-Simulator-Netzwerk hin. Ich muss https verwenden, um eine Verbindung herzustellen, da http fehlschlägt, bevor eine Anfrage gesendet wird.
ptc

5
Hey Leute, ich habe genau das gleiche Problem auf dem Gerät. Gibt es eine Lösung dafür? Unter iOS 7 gibt es jedoch kein Problem.
Andres C

9
Tipp: Sie können die NSURLErrorNetworkConnectionLostKonstante anstelle der Hardcodierung verwenden -1005.
Vincent Tourraine

6
Dieses Problem ist unter iOS 11.2.6 weiterhin vorhanden.
Makalele

47

Bei mir Resetting content and settingsfunktioniert Simulator. Gehen Sie folgendermaßen vor, um den Simulator zurückzusetzen:

iOS Simulator -> Inhalt und Einstellungen zurücksetzen -> Zurücksetzen drücken (auf die Warnung, die kommen wird)


29

Die Laufzeit des iOS 8.0-Simulators weist einen Fehler auf. Wenn sich Ihre Netzwerkkonfiguration während des Startvorgangs des simulierten Geräts ändert, denken übergeordnete APIs (z. B. CFNetwork) in der simulierten Laufzeit, dass die Netzwerkverbindung verloren gegangen ist. Derzeit wird empfohlen, das simulierte Gerät einfach neu zu starten, wenn sich Ihre Netzwerkkonfiguration ändert.

Wenn Sie von diesem Problem betroffen sind, legen Sie unter http://bugreport.apple.com zusätzliche doppelte Radargeräte ab , um die Priorität zu erhöhen.

Wenn Sie dieses Problem sehen, ohne die Netzwerkkonfigurationen geändert zu haben, ist dies kein bekannter Fehler, und Sie sollten auf jeden Fall ein Radar einreichen, um anzuzeigen, dass das Problem nicht der bekannte Fehler ist, der durch die Netzwerkkonfiguration geändert wurde.


7
Ich habe dieses Problem auch auf einem Gerät.
Darren

@darren Dann ist es nicht das Problem, auf das ich mich bezog. Ich schlage vor, Sie legen ein Radar ab.
Jeremy Huddleston Sequoia

4
Bitte geben Sie Ihre Radar-ID an, damit das
Ablegen von

11

Was das Problem für mich löste, war, den Simulator neu zu starten und Inhalte und Einstellungen zurückzusetzen.


Es ist auch hilfreich, die App vor dem Zurücksetzen des Simulators zu beenden und den Mac neu zu starten. Ich wechsle oft die Plätze mit verschiedenen WLAN-Spots und dies ist ein Verfahren, das das Problem für mich behebt.
Vladimír Slavík

11

Außerdem tritt unter iOS 8 Simulator ein Problem mit Beta 5 und AFNetworking 1.3 auf, das zu einem Verbindungsfehler führt:

Domain = NSURLErrorDomain Code = -1005 "Die Netzwerkverbindung wurde unterbrochen."

Der gleiche Code funktioniert gut auf iOS 7- und 7.1-Simulatoren, und mein Debugging-Proxy zeigt, dass der Fehler auftritt, bevor tatsächlich eine Verbindung versucht wird (dh keine Anforderungen protokolliert werden).

Ich habe den Fehler bei NSURLConnection verfolgt und Apple einen Fehler gemeldet. Siehe Zeile 5 im beigefügten Bild:

Der NSURLConnection-Clientdelegat ist fehlgeschlagen.

Das Ändern der Verwendung httpsermöglicht die Verbindung von iOS 8-Simulatoren, wenn auch mit zeitweiligen Fehlern.

Das Problem ist in Xcode 6.01 (g) immer noch vorhanden.


Ich sehe das gleiche Problem mit NSURLSession und NSURLConnection, das das Problem mit AFNetworking ausschließt. Außerdem habe ich festgestellt, dass es mit https funktioniert und mit http fehlschlägt. Ich konnte immer noch keine Lösung finden. Hast du eine Lösung?
VoidStack

Keine Lösung wurde gemeldet, da ein Fehler (18072300) einen Kommentar zur Arbeit mit https hinzufügt, der gute Informationen enthält.
ptc

Könnten Sie den Bug-Link hier einfügen? Vielen Dank, weil ich denke, ich habe das gleiche Problem, aber ich benutze nur die NSURLConnection (und Delegaten), aber ich bekomme die gleiche Fehlermeldung
szuniverse

Apple-Fehlerbericht kann nicht freigegeben werden. Immer noch offen und immer noch in XCODE 6 Beta 7 vorhanden. Wenn Sie auch einen Fehlerbericht einreichen, hilft dies bei der Priorität.
ptc

Sieht so aus, als ob dieses Problem im iOS-Simulator auftritt und ich mit dem tatsächlichen Gerät müde bin, es funktioniert einwandfrei. Weiteres Debuggen Ich fand ein Problem mit dem Port auf dem iOS-Simulator, https-Port 443 funktioniert einwandfrei und ich habe 8080 für http verwendet, das früher fehlgeschlagen ist. Ich habe versucht, andere Ports zu verwenden und konnte auf dem iOS-Simulator einen http-Anruf tätigen. Sieht aus wie ein Fehler in Beta Xcode 6, muss auf stabilen Xcode 6 warten.
VoidStack

10

Dieses Problem trat bei der Verwendung von Alamofire auf. Mein Fehler war, dass ich [:]auf GETAnfrage ein leeres Wörterbuch für die Parameter gesendet habe, anstatt nilParameter zu senden .

Hoffe das hilft!


GET und POST mit dem leeren Wörterbuch [:] verursachen diesen Fehler zufällig. Ich verwende Python Flask für die Backend-REST-APIs. Dies kann auch nützlich sein.
Mahmoud Fayez

10

Das Öffnen von Charles hat das Problem für mich gelöst, was sehr seltsam erscheint ...

Charles ist ein HTTP-Proxy / HTTP-Monitor / Reverse-Proxy, mit dem Entwickler den gesamten HTTP- und SSL / HTTPS-Verkehr zwischen ihrem Computer und dem Internet anzeigen können. Dies umfasst Anforderungen, Antworten und die HTTP-Header (die die Cookies und Caching-Informationen enthalten).


1
Das funktioniert auch für mich, ich denke, weil Charles ein SSL-Zertifikat verwendet, um den Sumulator zu vertreten, fordert er einen ähnlichen Trick an wie https
thisispete

1
Das funktioniert bei mir immer! Habe es 30 Mal versucht und es funktioniert 30 von 30. Ich dachte, es wäre ein Zufall, aber gut zu wissen, dass ich es einfach nicht bin.
JDOG

2
Charles ist ein Proxy-Tool, mit dem Sie den Datenverkehr von Ihrem Computer aus überwachen können. Überprüfen Sie charlesproxy.com für Details. Das Charles SSL-Zertifikat kann die Fähigkeit des Simulators beeinträchtigen, Netzwerkanforderungen zu stellen.
Colin Tremblay

@ColinTremblay Ich denke, Ihr Simulator / Gerät ist für die Verwendung von Proxy konfiguriert. Das Entfernen des Proxys funktioniert ebenfalls.
Bikram990

Lächerlicherweise hat das auch bei mir funktioniert. Charles musste geöffnet sein und dann die iOS Simulator-Einstellungen zurücksetzen.
Matt Andrews

6

Siehe pjebs Kommentar am 5. Januar auf Github.

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

Einige schlagen außerdem vor, erneut eine Verbindung zur Site herzustellen.

dh ZWEIMAL die POST-Anfrage auslösen

Lösung: Verwenden Sie eine Methode, um eine Verbindung zur Site herzustellen. Geben Sie (id) zurück. Wenn die Netzwerkverbindung unterbrochen wurde, kehren Sie zurück, um dieselbe Methode zu verwenden.

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

}

Methode 1 hat mir sehr geholfen. Danke
Abhishek Mitra

4

Ich habe diesen Fehler auch erhalten, aber auf tatsächlichen Geräten und nicht auf dem Simulator. Wir haben den Fehler beim Zugriff auf unser Heroku-Backend über HTTPS (Gunicorn Server) und beim POSTS mit großen Körpern (alles über 64 KB) festgestellt. Wir verwenden HTTP Basic Auth zur Authentifizierung und haben festgestellt, dass der Fehler behoben wurde, indem NICHT die didReceiveChallenge:Delegate-Methode für NSURLSession verwendet wurde, sondern die Authentifizierung durch Hinzufügen in den ursprünglichen Anforderungsheader eingebrannt wurde Authentiation: Basic <Base64Encoded UserName:Password>. Dies verhindert, dass das zum Auslösen der didReceiveChallenge:Delegatennachricht erforderliche 401 und die nachfolgende Netzwerkverbindung unterbrochen werden.


Vielen Dank für Ihren wertvollen Kommentar. Sie haben Recht, wenn ich die base64-Zeichenfolge eines Bildes unter 64 KB hochlade, wird es erfolgreich hochgeladen.
Vinayak Bhor

3

Ich hatte das gleiche Problem. Lösung war einfach, ich habe festgelegt HTTPBody, aber noch nicht festgelegt HTTPMethodzu POST. Nachdem dies behoben war, war alles in Ordnung.


3

Ich hatte das gleiche Problem. Ich weiß nicht, wie AFNetworking die https-Anforderung implementiert, aber der Grund für mich ist das Cache-Problem der NSURLSession.

Nachdem meine Anwendung von der Safari zurückverfolgt und dann eine http-Anfrage gesendet hat, wird der Fehler "http load load 1005" angezeigt. Wenn ich die Verwendung aufhöre "[NSURLSession sharedSession]", aber eine konfigurierbare NSURLSession-Instanz zum Aufrufen der Methode "dataTaskWithRequest:" wie folgt verwende, ist das Problem behoben.

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

Denken Sie daran zu setzen config.URLCache = nil;.


1
Ich denke, all diejenigen, die das Gerät / den Simulator neu starten oder Daten zurücksetzen, sollten sich mit dieser Antwort befassen. Für mich scheinen alle ihre Aktionen den Cache zu leeren, wodurch das Problem tatsächlich behoben wird. Es ist also wahrscheinlich ein Problem mit dem URL-Cache. Ich werde es jetzt testen.
Kamran Khan

2

Ich musste XCode beenden, den Inhalt des DerivedData-Ordners löschen (~ / Library / Developer / Xcode / DerivedData oder / Library / Developer / Xcode / DerivedData) und den Simulator beenden, damit dies funktioniert.


1
Die einzige relevante Aktion in dieser Liste war der Neustart des Simulators. Das Neustarten von Xcode und das Löschen abgeleiteter Daten ist zu lang.
Jeremy Huddleston Sequoia

2

Ich habe dieses Problem auch auf einem iOS 8-Gerät. Es ist etwas mehr detailliert hier und scheint ein Fall von iOS zu versuchen , Verbindungen zu verwenden , die bereits abgelaufen sind out. Mein Problem ist nicht dasselbe wie das in diesem Link erläuterte Keep-Alive-Problem, es scheint jedoch dasselbe Endergebnis zu sein.

Ich habe mein Problem behoben, indem ich einen rekursiven Block ausgeführt habe, wenn ich den Fehler -1005 erhalte. Dadurch wird die Verbindung schließlich durchgestellt, obwohl die Rekursion manchmal mehr als 100 Mal wiederholt werden kann, bevor die Verbindung funktioniert, jedoch nur eine Sekunde zum Ausführen hinzugefügt wird Ich wette, das ist genau die Zeit, die der Debugger benötigt, um die NSLogs für mich zu drucken.

So führe ich einen rekursiven Block mit AFNetworking aus: Fügen Sie diesen Code Ihrer Verbindungsklassendatei hinzu

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

Dann benutze es so:

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

Sie werden sehen, dass ich eine AFHTTPRequestOperationUnterklasse verwende, aber Ihren eigenen Anforderungscode hinzufüge. Der wichtige Teil ist das Aufrufen recurse(@offset.intValue+1));, damit der Block erneut aufgerufen wird.


Was ist die MyAFHTTPRequestOperation-Klasse?
JDOG

Es ist nur eine AFHTTPRequestOperation-Unterklasse. Ich benutze es, um einige Dinge wie Timeout und Authentifizierung vorzugeben.
Darren

2

Wenn das Problem auf einem Gerät auftritt, überprüfen Sie, ob Datenverkehr über einen Proxy geleitet wird (Einstellungen> Wi-Fi> (Info)> HTTP-Proxy). Ich hatte mein Gerät für Charles eingerichtet, vergaß aber den Proxy. Scheint, dass dieser Fehler auftritt, ohne dass Charles ihn tatsächlich ausführt.


2

Wenn beim Hochladen von Dateien auf einen Back-End-Server jemand diese Fehlermeldung erhält, stellen Sie sicher, dass der empfangende Server über eine maximale Inhaltsgröße verfügt, die für Ihre Medien zulässig ist. In meinem Fall benötigte NGINX einen höheren Wert client_max_body_size. NGINX lehnte die Anforderung ab, bevor das Hochladen durchgeführt wurde, sodass kein Fehlercode zurückkam.


2

Ich habe den Fehler auf einem iOS 7-Gerät erhalten, als ich Xcode 6.2 Beta verwendet habe.

Das Zurückschalten von Xcode 6.2 Beta auf 6.1.1 hat das Problem behoben, zumindest auf einem iOS 7-Gerät.


Ich glaube nicht, dass es etwas zu lösen gibt: Das zugrunde liegende Betriebssystem trennt die Verbindung aus einem legitimen Grund oder nicht. Eine App sollte darauf vorbereitet sein (offline arbeiten oder was auch immer). Angenommen, das SDK in Ihrer speziellen Xcode-Version ist natürlich nicht fehlerhaft: Wie meine Antwort andeutet, war 6.2 höchstwahrscheinlich fehlerhaft, während 6.1.1 gut war. Ähnliches kann jetzt beobachtet werden, wenn xcode 6.4 einigermaßen stabil erscheint, während 7.0.1 eine Alpha-Software ist. Zumindest scheint es so.
Anton Tropashko

2

Auf 2017-01-25Apple wurde ein technisches Q & A zu diesem Fehler veröffentlicht:

Technische Fragen und Antworten zu Apple QA1941

Behandlung von Fehlern bei der Netzwerkverbindung wurde unterbrochen

A: NSURLErrorNetworkConnectionLost ist der Fehler -1005 in der Fehlerdomäne NSURLErrorDomain und wird den Benutzern als "Die Netzwerkverbindung wurde unterbrochen" angezeigt. Dieser Fehler bedeutet, dass die zugrunde liegende TCP-Verbindung, die die HTTP-Anforderung enthält, während der Ausführung der HTTP-Anforderung getrennt wurde (weitere Informationen hierzu finden Sie weiter unten). Unter bestimmten Umständen kann NSURLSession solche Anforderungen automatisch wiederholen (insbesondere wenn die Anforderung idempotent ist), unter anderen Umständen ist dies nach den HTTP-Standards nicht zulässig.

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


1

Ich habe das Problem monatelang bekommen und schließlich festgestellt, dass beim Deaktivieren von DNSSEC auf unserer API-Domain alles in Ordnung war: simple_smile:


2
Könnten Sie bitte näher darauf eingehen?
Groot

1

Ich habe eine Verbindung über ein VPN hergestellt. Durch Deaktivieren des VPN wurde das Problem behoben.


1

Ich habe diesen Fehler festgestellt, als ich eine NSURLRequest an eine NSURLSession übergeben habe, ohne die HTTPMethod der Anforderung festzulegen .

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

Error Domain = NSURLErrorDomain Code = -1005 "Die Netzwerkverbindung wurde unterbrochen."

Fügen Sie das hinzu HTTPMethod, und die Verbindung funktioniert einwandfrei

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

1

Testen Sie, ob Sie andere Apps (z. B. Safari) anfordern können. Wenn nicht, ist möglicherweise etwas auf Ihrem Computer. In meinem Fall hatte ich dieses Problem mit Avast Antivirus, das meine Simulatoranforderung blockierte (fragen Sie mich nicht warum).


1

Durch einen Neustart des Computers wurde das Problem mit Xcode9.1 behoben. Ich hatte den Simulator und Xcode neu gestartet, es funktioniert nicht.


1

Ich hatte das gleiche Problem: Ich habe Network Link Conditioner für langsame Netzwerktests für die App aktiviert. Das hat diesen Fehler manchmal verursacht. Wenn ich ihn deaktiviert habe Settings > Developer > Network Link Conditioner, hat er mein Problem gelöst.

Geben Sie hier die Bildbeschreibung ein

Hoffe das hilft jemandem.


1

In meinem Fall lag es daran, dass ich eine Verbindung zu HTTP herstellte und es auf HTTPS lief


0

Ich hatte dieses Problem aus folgendem Grund.

TLDR: Überprüfen Sie, ob Sie eine GETAnforderung senden, die die Parameter für die URL anstatt für die NSURLRequest's HTTBodyEigenschaft senden soll .

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

Ich hatte eine Netzwerkabstraktion in meine App eingebunden und sie funktionierte für alle meine Anfragen ziemlich gut.

Ich habe eine neue Anfrage zu einem anderen Webdienst hinzugefügt (nicht zu meinem eigenen), und dieser Fehler hat mich ausgelöst.

Ich ging zu einem Spielplatz und begann von Grund auf, eine Barebone-Anfrage zu erstellen, und es funktionierte. Also näherte ich mich meiner Abstraktion, bis ich die Ursache fand.

Meine Abstraktionsimplementierung hatte einen Fehler: Ich habe eine Anfrage gesendet, die in der URL codierte Parameter senden sollte, und ich habe die NSURLRequest's HTTBodyEigenschaft auch mit den Abfrageparametern gefüllt . Sobald ich das entfernte HTTPBody, funktionierte es.


0

Ich habe diesen Fehler erhalten und festgestellt, dass die Anwendung Postman ebenfalls heruntergefallen ist, aber in der App Advanced Rest Client (ARC) und in Android funktioniert hat. Also musste ich Charles installieren, um die Kommunikation zu debuggen, und ich bemerke, dass der Antwortcode -1 war. Das Problem war, dass der REST-Programmierer vergessen hat, den Antwortcode 200 zurückzugeben.

Ich hoffe, dass dies anderen Entwicklern hilft.


0

Wenn der Fehler -1005 angezeigt wird, muss die API erneut aufgerufen werden.

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

Sie müssen Ihren Code hinzufügen, um die Funktion erneut aufzurufen. Stellen Sie sicher, dass Sie einmal eine Aufrufmethode waren, andernfalls eine rekursive Aufrufschleife.


0

Neben all den Antworten habe ich eine schöne Lösung gefunden. Tatsächlich ist das Problem im Zusammenhang mit dem Ausfall der Netzwerkverbindung für das iOS 12-Onword darauf zurückzuführen, dass das iOS 12.0-Onword einen Fehler aufweist. Und es noch zu lösen. Ich hatte die Git-Hub-Community wegen eines AFNetworking-Problems durchgesehen, als die App aus dem Hintergrund kam und versuchte, einen Netzwerkanruf zu tätigen, und beim Verbindungsaufbau fehlschlug. Ich verbringe 3 Tage damit und versuche viele Dinge, um die Ursache dafür zu finden und habe nichts gefunden. Endlich habe ich etwas Licht im Dunkeln, als ich diesen Blog rot habe https://github.com/AFNetworking/AFNetworking/issues/4279

Es wird gesagt, dass es einen Fehler in iOS 12 gibt. Grundsätzlich können Sie nicht erwarten, dass ein Netzwerkanruf jemals abgeschlossen wird, wenn die App nicht im Vordergrund steht. Und aufgrund dieses Fehlers werden die Netzwerkanrufe abgebrochen und wir erhalten Netzwerkfehler in Protokollen.

Mein bester Vorschlag an Sie ist, eine gewisse Verzögerung vorzusehen, wenn Ihre App vom Hintergrund in den Vordergrund kommt und ein Netzwerkanruf erfolgt. Führen Sie diesen Netzwerkanruf im Versand asynchron mit einer gewissen Verzögerung durch. Sie werden niemals Netzwerkanrufe oder Verbindungsverlust bekommen.

Warten Sie nicht, bis Apple dieses Problem für iOS 12 lösen lässt, da es noch nicht behoben ist. Sie können diese Problemumgehung durchführen, indem Sie eine Verzögerung für Ihre Netzwerkanforderung angeben, z. B. NSURLConnection, NSURLSession oder AFNetworking oder ALAMOFIRE. Prost :)


0

Ich hatte das gleiche Problem, als ich über die iOS 12-App mit einem physischen Gerät auf dem Server meines Unternehmens anrief. Das Problem war, dass die Serverfestplatte voll war. Das Freigeben von Speicherplatz auf dem Server löste das Problem.

Ich habe den gleichen Fehler in einer anderen Situation gefunden, die meiner Meinung nach auf eine Zeitüberschreitung zurückzuführen ist, die nicht über die von Apple ( URLSession.timeoutIntervalForRequestund URLSession.timeoutIntervalForResource) bereitgestellte Standard-Netzwerk-API parametrierbar ist . Auch dort .. Server Antwort schneller gemacht löste das Problem

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.