Domaine d'erreur = NSURLErrorDomain Code = -1005 «La connexion réseau a été perdue.»

J'ai une application qui fonctionne bien sur Xcode6-Beta1 et Xcode6-Beta2 avec iOS7 et iOS8. Mais avec Xcode6-Beta3, Beta4, Beta5, je rencontre des problèmes de réseau avec iOS8, mais tout fonctionne bien sur iOS7. Je reçois l'erreur "The network connection was lost.". L'erreur est la suivante:

Erreur: Error Domain = NSURLErrorDomain Code = -1005 "La connexion réseau a été perdue." UserInfo = 0x7ba8e5b0 {NSErrorFailingURLStringKey =, _kCFStreamErrorCodeKey = 57, NSErrorFailingURLKey =, NSLocalizedDescription = La connexion réseau a été perdue., _KCFStreamErrorDomainKey = 1, NSUnderlyingError = 0x7a6957 "

J'utilise AFNetworking 2.x et l'extrait de code suivant pour effectuer l'appel réseau:

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

J'ai essayé NSURLSessionmais je reçois toujours la même erreur.

Le redémarrage du simulateur a résolu le problème pour moi.

Nous avons eu cette erreur exacte et cela s'est avéré être un problème avec l'implémentation HTTP sous-jacente de NSURLRequest:

Pour autant que nous puissions le dire, lorsque iOS 8/9/10/11 reçoit une réponse HTTP avec un en- Keep-Alivetête, il conserve cette connexion pour la réutiliser plus tard (comme il se doit), mais il la conserve plus que le timeoutparamètre du En-tête Keep-Alive (il semble que la connexion reste toujours active pendant 30 secondes.) Ensuite, lorsqu'une deuxième demande est envoyée par l'application moins de 30 secondes plus tard, elle essaie de réutiliser une connexion qui aurait pu être abandonnée par le serveur. (si plus que le réel Keep-Alives'est écoulé).

Voici les solutions que nous avons trouvées jusqu'à présent:

• Augmentez le paramètre de délai d'expiration du serveur au-dessus de 30 secondes. Il semble que iOS se comporte toujours comme si le serveur maintenait la connexion ouverte pendant 30 secondes, quelle que soit la valeur fournie dans l'en-tête Keep-Alive. (Cela peut être fait pour Apache en définissant l' KeepAliveTimeoutoption.
• Vous pouvez simplement désactiver le mécanisme de maintien en vie pour les clients iOS en fonction de l'agent utilisateur de votre application (par exemple pour Apache: BrowserMatch "iOS 8\." nokeepalivedans le fichier mod setenvif.conf)
• Si vous n'avez pas accès au serveur, vous pouvez essayer d'envoyer vos demandes avec un en- Connection: closetête: cela indiquera au serveur d'interrompre la connexion immédiatement et de répondre sans aucun en-tête Keep Alive. MAIS pour le moment, NSURLSession semble remplacer l'en- Connectiontête lorsque les demandes sont envoyées (nous n'avons pas testé cette solution de manière approfondie car nous pouvons modifier la configuration d'Apache)

Pour le mien, Resetting content and settingsde Simulator fonctionne. Pour réinitialiser le simulateur, suivez les étapes:

iOS Simulator -> Réinitialiser le contenu et les paramètres -> Appuyez sur Réinitialiser (sur l'avertissement qui viendra)

Le runtime du simulateur iOS 8.0 a un bogue selon lequel si votre configuration réseau change pendant le démarrage du périphérique simulé, les API de niveau supérieur (par exemple: CFNetwork) dans le runtime simulé penseront qu'il a perdu la connectivité réseau. Actuellement, la solution de contournement recommandée consiste à redémarrer simplement le périphérique simulé lorsque la configuration de votre réseau change.

Si vous êtes concerné par ce problème, veuillez déposer des radars en double supplémentaires sur http://bugreport.apple.com pour obtenir une priorité accrue.

Si vous voyez ce problème sans avoir modifié les configurations réseau, ce n'est pas un bogue connu, et vous devez absolument déposer un radar, indiquant que le problème n'est pas le bogue connu de la configuration réseau modifiée.

ce qui a résolu le problème pour moi était de redémarrer le simulateur et de réinitialiser le contenu et les paramètres.

Vous avez également un problème avec la version bêta 5 et AFNetworking 1.3 lors de l'exécution sur le simulateur iOS 8 qui entraîne une erreur de connexion:

Domain = NSURLErrorDomain Code = -1005 "La connexion réseau a été perdue."

Le même code fonctionne bien sur les simulateurs iOS 7 et 7.1 et mon proxy de débogage montre que l'échec se produit avant qu'une tentative de connexion ne soit réellement tentée (c.-à-d. Aucune demande enregistrée).

J'ai suivi l'échec de NSURLConnection et signalé un bogue à Apple. Voir la ligne 5 dans l'image ci-jointe:

.

Le changement d'utilisation httpspermet la connexion à partir de simulateurs iOS 8, mais avec des erreurs intermittentes.

Le problème est toujours présent dans Xcode 6.01 (gm).

J'ai rencontré ce problème lors de l'utilisation d'Alamofire. Mon erreur était que j'envoyais un dictionnaire vide [:]pour les paramètres d'une GETdemande, plutôt que d'envoyer des nilparamètres.

J'espère que cela t'aides!

L'ouverture de Charles a résolu le problème pour moi, ce qui semble très étrange ...

Charles est un proxy HTTP / moniteur HTTP / proxy inverse qui permet à un développeur de visualiser tout le trafic HTTP et SSL / HTTPS entre sa machine et Internet. Cela inclut les demandes, les réponses et les en-têtes HTTP (qui contiennent les cookies et les informations de mise en cache).

Voir le commentaire de pjebs le 5 janvier sur Github.

Méthode 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;
}

Certains suggèrent également de se reconnecter au site,

c'est-à-dire tirer la demande POST DEUX FOIS

Solution: utilisez une méthode pour établir la connexion au site, renvoyez (id), si la connexion réseau a été perdue, revenez pour utiliser la même méthode.

Méthode 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;
     }

}

J'obtenais également cette erreur, mais sur des appareils réels plutôt que sur le simulateur. Nous avons remarqué l'erreur lors de l'accès à notre backend heroku sur HTTPS (serveur gunicorn) et lors des POSTS avec de gros bodys (plus de 64 Ko). Nous utilisons HTTP Basic Auth pour l'authentification, et nous avons remarqué que l'erreur a été résolue en n'utilisant PAS la didReceiveChallenge:méthode déléguée sur NSURLSession, mais en créant plutôt l'authentification dans l'en-tête de demande d'origine via l'ajout Authentiation: Basic <Base64Encoded UserName:Password>. Cela empêche le 401 nécessaire pour déclencher le didReceiveChallenge:message délégué et la connexion réseau suivante perdue.

J'ai eu le même problème. La solution a été simple, je me suis fixé HTTPBody, mais ne l' ai pas mis HTTPMethodà POST. Après avoir corrigé cela, tout allait bien.

J'ai eu le même problème. Je ne sais pas comment AFNetworking implémente la requête https, mais la raison pour moi est le problème de cache de NSURLSession.

Après le suivi de mon application depuis Safari et après avoir posté une demande http, l'erreur "http load failed 1005" apparaîtra. Si j'arrête d'utiliser "[NSURLSession sharedSession]", mais pour utiliser une instance NSURLSession configurable pour appeler la méthode "dataTaskWithRequest:" comme suit, le problème est résolu.

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

N'oubliez pas de régler config.URLCache = nil;.

J'ai dû quitter XCode, supprimer le contenu du dossier DerivedData (~ / Library / Developer / Xcode / DerivedData ou / Library / Developer / Xcode / DerivedData) et quitter le simulateur pour que cela fonctionne.

J'ai également ce problème, fonctionnant sur un appareil iOS 8. Il est détaillé ici et semble être un cas où iOS essaie d'utiliser des connexions qui ont déjà expiré. Mon problème n'est pas le même que le problème Keep-Alive expliqué dans ce lien, mais il semble être le même résultat final.

J'ai corrigé mon problème en exécutant un bloc récursif chaque fois que je reçois une erreur -1005 et cela fait que la connexion finit par passer même si parfois la récursivité peut boucler plus de 100 fois avant que la connexion fonctionne, mais cela n'ajoute qu'une seconde à l'exécution fois et je parie que c'est juste le temps qu'il faut au débogueur pour imprimer les NSLog pour moi.

Voici comment j'exécute un bloc récursif avec AFNetworking: Ajoutez ce code à votre fichier de classe de connexion

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

Ensuite, utilisez-le comme ceci:

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

Vous verrez que j'utilise une AFHTTPRequestOperationsous - classe mais ajoutez votre propre code de demande. La partie importante appellerecurse(@offset.intValue+1)); pour que le bloc soit rappelé.

Si le problème se produit sur un appareil, vérifiez si le trafic passe par un proxy (Paramètres> Wi-Fi> (info)> Proxy HTTP). J'ai eu la configuration de mon appareil à utiliser avec Charles, mais j'ai oublié le proxy. Semble que sans Charles réellement exécuter cette erreur se produit.

Si quelqu'un obtient cette erreur lors du téléchargement de fichiers sur un serveur principal, assurez-vous que le serveur de réception a une taille de contenu maximale autorisée pour votre média. Dans mon cas, NGINX nécessitait une version supérieure client_max_body_size. NGINX rejetterait la demande avant le téléchargement, donc aucun code d'erreur n'est revenu.

J'obtenais l'erreur sur un appareil iOS 7 lorsque j'utilisais Xcode 6.2 beta.

Le retour de Xcode 6.2 beta à 6.1.1 a résolu le problème, au moins sur un appareil iOS 7.

Sur 2017-01-25Apple a publié un Q&A technique concernant cette erreur:

Questions et réponses techniques Apple QA1941

Gestion des erreurs «La connexion réseau a été perdue»

R: NSURLErrorNetworkConnectionLost est une erreur -1005 dans le domaine d'erreur NSURLErrorDomain et s'affiche pour les utilisateurs comme «La connexion réseau a été perdue». Cette erreur signifie que la connexion TCP sous-jacente qui transporte la demande HTTP s'est déconnectée pendant que la demande HTTP était en cours (voir ci-dessous pour plus d'informations à ce sujet). Dans certaines circonstances, NSURLSession peut réessayer de telles demandes automatiquement (en particulier, si la demande est idempotente) mais dans d'autres circonstances, ce n'est pas autorisé par les normes HTTP.

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

J'ai eu le problème pendant des mois et j'ai finalement découvert que lorsque nous désactivions DNSSEC sur notre domaine api, tout allait bien: simple_smile:

Je me connectais via un VPN. La désactivation du VPN a résolu le problème.

Je rencontrais cette erreur lors du passage d'une NSURLRequest à une NSURLSession sans définir la HTTPMethod de la demande .

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

Domain Error = NSURLErrorDomain Code = -1005 "La connexion réseau a été perdue."

Ajoutez le HTTPMethod, cependant, et la connexion fonctionne bien

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

Testez si vous pouvez demander à d'autres applications (comme safari). Sinon, il pourrait y avoir quelque chose sur votre ordinateur. Dans mon cas, j'ai eu ce problème avec Avast Antivirus, qui bloquait ma demande de simulateurs (ne me demandez pas pourquoi).

Le redémarrage de l'ordinateur a résolu le problème pour moi avec Xcode9.1. J'avais redémarré le simulateur et Xcode, ça ne marche pas.

J'étais confronté au même problème, j'ai activé Network Link Conditioner pour les tests de réseau lents pour l'application. Cela créait parfois cette erreur, lorsque je l'ai désactivée Settings > Developer > Network Link Conditioner, cela a résolu mon problème.

J'espère que cela aidera quelqu'un.

En plus de toutes les réponses, j'ai trouvé une bonne solution. En fait, le problème lié à l'échec de la connexion réseau pour onword iOS 12 est dû au fait qu'il y a un bogue dans l'onword iOS 12.0. Et cela n'a pas encore été résolu. J'étais passé par la communauté git hub pour un problème lié à AFNetworking lorsque l'application venait de l'arrière-plan et essayait de faire un appel réseau et échouait lors de l'établissement de la connexion. J'y passe 3 jours et essaie beaucoup de choses pour en arriver à la cause profonde de cela et je n'ai rien trouvé. Enfin, j'ai eu un peu de lumière dans l'obscurité lorsque j'ai rouge ce blog https://github.com/AFNetworking/AFNetworking/issues/4279

Cela signifie qu'il y a un bogue dans l'iOS 12. Fondamentalement, vous ne pouvez pas vous attendre à ce qu'un appel réseau soit terminé si l'application n'est pas au premier plan. Et en raison de ce bogue, les appels réseau sont interrompus et le réseau échoue dans les journaux.

Ma meilleure suggestion est de prévoir un certain délai lorsque votre application passe de l'arrière-plan au premier plan et qu'il y a un appel réseau. Effectuez cet appel réseau dans l'async de répartition avec un certain retard. Vous n'obtiendrez jamais de coupure d'appel réseau ni de perte de connexion.

N'attendez pas qu'Apple laisse ce problème se résoudre pour iOS 12 car il reste à résoudre. Vous pouvez suivre cette solution de contournement en prévoyant un certain retard pour votre demande de réseau, à savoir NSURLConnection, NSURLSession ou AFNetworking ou ALAMOFIRE. À votre santé :)

Dans mon cas, c'était parce que je me connectais à HTTP et qu'il fonctionnait sur HTTPS

J'avais ce problème pour la raison suivante.

TLDR: Vérifiez si vous envoyez une GETdemande qui devrait envoyer les paramètres sur l'url plutôt que sur la NSURLRequest's HTTBodypropriété.

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

J'avais monté une abstraction réseau sur mon application, et cela fonctionnait assez bien pour toutes mes demandes.

J'ai ajouté une nouvelle demande à un autre service Web (pas le mien) et il a commencé à me renvoyer cette erreur.

Je suis allé à une aire de jeux et j'ai commencé à partir de zéro pour créer une demande de base, et cela a fonctionné. J'ai donc commencé à me rapprocher de mon abstraction jusqu'à ce que j'en trouve la cause.

Mon implémentation d'abstraction avait un bug: j'envoyais une requête qui était censée envoyer des paramètres encodés dans l'url et je remplissais également la NSURLRequest's HTTBodypropriété avec les paramètres de requête. Dès que j'ai retiré le, HTTPBodycela a fonctionné.

Je recevais cette erreur et remarquais également que l'application Postman tombait également mais fonctionnait dans l'application Advanced Rest Client (ARC) et fonctionnait dans Android. J'ai donc dû installer Charles pour déboguer la communication et j'ai remarqué que le code de réponse était -1. Le problème était que le programmeur REST avait oublié de renvoyer le code de réponse 200.

J'espère que cela aidera d'autres développeurs.

Chaque fois que vous obtenez l'erreur -1005, vous devez à nouveau appeler l'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... 
       }
  }];

Vous devez ajouter à nouveau votre code pour appeler la fonction. Assurez-vous que vous étiez la méthode d'appel une fois sinon sa boucle récursive d'appel.

J'ai rencontré le même problème lors de l'appel en utilisant le serveur de mon entreprise depuis l'application iOS 12 avec un appareil physique. Le problème était que le disque dur du serveur était plein. La libération d'espace sur le serveur a résolu le problème.

J'ai trouvé la même erreur dans une autre situation, je pense, en raison d'un délai non paramétrable via l'API de mise en réseau standard fournie par Apple ( URLSession.timeoutIntervalForRequestet URLSession.timeoutIntervalForResource). Même là .. la réponse du serveur plus rapide a résolu le problème