J'ai une application qui fonctionne très bien sur Xcode6-Beta1 et Xcode6-Beta2 avec iOS7 et iOS8. Mais avec Xcode6-Beta3, Beta4, Beta5, je suis confronté à des problèmes de réseau avec iOS8 mais tout fonctionne correctement sur iOS7. Je reçois l'erreur "The network connection was lost."
. L'erreur est la suivante:
Erreur: Domaine d'erreur = Code NSURLErrorDomain = -1005 "La connexion réseau a été perdue." UserInfo = 0x7ba8e5b0 {NSErrorFailingURLStringKey =, _kCFStreamErrorCodeKey = 57, NSErrorFailingURLKey =, NSLocalizedDescription = La connexion réseau a été perdue.
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é NSURLSession
mais 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
:
Autant que nous sachions, lorsque iOS 8/9/10/11 reçoit une réponse HTTP avec un en-tête Keep-Alive
, il garde cette connexion pour qu'elle soit réutilisée plus tard (comme il se doit), mais elle le conserve pour plus que le paramètre timeout
. de l'en-tête Keep-Alive (il semble que la connexion reste active pendant 30 secondes.) Ensuite, lorsqu'une deuxième demande est envoyée par l'application moins de 30 secondes plus tard, l'application tente de réutiliser une connexion susceptible d'avoir été abandonné par le serveur (si plus que le Keep-Alive
réel s'est écoulé).
Voici les solutions que nous avons trouvées jusqu'à présent:
KeepAliveTimeout
.BrowserMatch "iOS 8\." nokeepalive
dans le fichier de mod setenvif.conf
).Connection: close
: cela indiquera au serveur de mettre immédiatement fin à la connexion et de répondre sans en-têtes Keep Alive. MAIS pour le moment, NSURLSession semble remplacer l'en-tête Connection
lorsque les demandes sont envoyées (nous n'avons pas testé cette solution de manière exhaustive car nous pouvons modifier la configuration d'Apache).Pour le mien, le Resetting content and settings
du simulateur fonctionne . Pour réinitialiser le simulateur, procédez comme suit:
simulateur iOS -> Réinitialiser le contenu et les paramètres -> Appuyez sur Réinitialiser (sur l'avertissement qui apparaîtra)
Le runtime du simulateur iOS 8.0 présente un bogue dans lequel, si la configuration de votre 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é vont penser qu'il a perdu la connectivité réseau. Actuellement, la solution conseillée consiste à simplement redémarrer le périphérique simulé lorsque la configuration de votre réseau change.
Si ce problème vous concerne, déposez des radars en double supplémentaires à l’adresse http://bugreport.Apple.com pour obtenir une priorité accrue.
Si vous voyez ce problème sans que ait modifié la configuration du réseau, il ne s'agit pas d'un bogue connu et vous devez absolument enregistrer un radar indiquant que le problème n'est pas le bogue connu qui a changé de configuration réseau.
Vous rencontrez également un problème avec la version bêta 5 et AFNetworking 1.3 lors de l'exécution sur le simulateur iOS 8, ce qui entraîne une erreur de connexion:
Domain = NSURLErrorDomain Code = -1005 "La connexion réseau a été perdue."
Le même code fonctionne correctement sur les simulateurs iOS 7 et 7.1 et mon proxy de débogage indique que la défaillance se produit avant la tentative de connexion (c'est-à-dire qu'aucune demande n'a été consignée).
J'ai suivi la défaillance de NSURLConnection et signalé un bogue à Apple. Voir la ligne 5 dans l'image ci-jointe:
.
Le passage à utiliser https
permet la connexion à partir de simulateurs iOS 8 avec des erreurs intermittentes.
Le problème est toujours présent dans Xcode 6.01 (gm).
ce qui a résolu le problème pour moi, c'est de redémarrer le simulateur et de réinitialiser le contenu et les paramètres.
Opening 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 voir 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).
Je rencontrais ce problème en utilisant Alamofire. Mon erreur a été d'envoyer un dictionnaire vide [:]
pour les paramètres d'une requête GET
, plutôt que d'envoyer des paramètres nil
.
J'espère que cela t'aides!
Voir le commentaire de pjebs du 5 janvier sur Github.
Méthode1:
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 Exécuter 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'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 par Safari, puis par l'envoi d'une requête http, l'erreur "HTTP load failed 1005" va s'afficher . Si j'arrête d'utiliser "[NSURLSession sharedSession]"
, mais d'utiliser une instance configurable NSURLSession pour appeler "dataTaskWithRequest:" méthode 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 définir config.URLCache = nil;
.
J'avais aussi cette erreur, mais sur des appareils réels plutôt que sur le simulateur. Nous avons remarqué l'erreur en accédant à notre back-up heroku sur HTTPS (serveur gunicorn) et en effectuant des POSTS avec de gros corps (plus de 64Ko). Nous utilisons HTTP Basic Auth pour l'authentification et avons remarqué que l'erreur avait été résolue en n'utilisant PAS la méthode déléguée didReceiveChallenge:
sur NSURLSession, mais en intégrant plutôt l'authentification dans l'en-tête de la requête d'origine en ajoutant Authentiation: Basic <Base64Encoded UserName:Password>
. Cela empêche le 401 nécessaire de déclencher le message de délégué didReceiveChallenge:
et la connexion réseau ultérieure perdue.
J'ai eu le même problème. La solution était simple. J'ai défini HTTPBody
, mais je n’ai pas défini HTTPMethod
à POST
. Après avoir réglé ça, tout allait bien.
Je devais quitter XCode, supprimer le contenu du dossier DerivedData (~/Bibliothèque/Developer/Xcode/DerivedData ou/Bibliothèque/Developer/Xcode/DerivedData) et quitter le simulateur pour que cela fonctionne.
J'ai ce problème également, fonctionnant sur un appareil iOS 8 . Il est détaillé un peu plus ici et semble être un cas d'iOS essayant d'utiliser des connexions qui ont déjà expiré . Mon problème n'est pas Ce n'est pas la même chose que le problème de Keep-Alive expliqué dans ce lien, mais il semble que ce soit le même résultat final.
J'ai corrigé mon problème en exécutant un bloc récursif chaque fois que je recevais une erreur -1005, ce qui a pour effet de faire passer la connexion même si parfois la récursion peut être mise en boucle plus de 100 fois avant que la connexion ne fonctionne, mais elle ajoute une simple seconde à l'exécution fois et je parie que c'est juste le temps qu'il faut au débogueur pour imprimer le NSLog pour moi.
Voici comment exécuter 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 sous-classe AFHTTPRequestOperation
mais que j'ajoute votre propre code de demande. La partie importante appelle recurse(@offset.intValue+1));
pour que le bloc soit rappelé.
Si quelqu'un rencontre cette erreur lors du téléchargement de fichiers sur un serveur principal, assurez-vous que la taille maximale du contenu du serveur de réception est autorisée pour votre média. Dans mon cas, NGINX avait besoin d'un client_max_body_size
plus élevé. NGINX rejetterait la demande avant que le téléchargement ne soit terminé, donc aucun code d'erreur ne revient.
Je recevais l'erreur sur un appareil iOS 7 lorsque j'utilisais Xcode 6.2 beta.
Le fait de revenir de Xcode 6.2 beta à 6.1.1 corrigeait le problème, du moins sur un appareil iOS 7.
J'ai eu le problème pendant des mois et nous avons finalement découvert que lorsque nous désactivions DNSSEC sur notre domaine api, tout allait bien: simple_smile:
Je frappais cette erreur en passant un NSURLRequest à un NSURLSession sans définir HTTPMethod de la requête .
NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:urlComponents.URL];
Error Domain = NSURLErrorDomain Code = -1005 "La connexion réseau a été perdue."
Ajoutez la HTTPMethod
, cependant, et la connexion fonctionne correctement
NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:urlComponents.URL];
[request setHTTPMethod:@"PUT"];
Je me connectais via un VPN. La désactivation du VPN a résolu le problème.
Testez si vous pouvez demander à d'autres applications (comme Safari). Sinon, cela pourrait être quelque chose sur votre ordinateur. Dans mon cas, j'avais 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, cela ne fonctionne pas.
Si le problème se produit sur un périphérique, vérifiez si le trafic passe par un proxy (Paramètres> Wi-Fi> (infos)> Proxy HTTP). J'avais la configuration de mon appareil à utiliser avec Charles, mais j'avais oublié le proxy. Il semble que sans Charles, cette erreur se produise.
Je recevais cette erreur et j'ai également remarqué que l'application Postman était également en train de tomber mais qu'elle fonctionnait dans l'application Advanced Rest Client (ARC) et dans Android . é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.
Dans mon cas, c’était parce que je me connectais à HTTP et fonctionnait sur HTTPS
Je rencontrais le même problème, J'ai activé Network Link Conditioner pour des tests de réseau lents pour l'application. Cela créait parfois cette erreur, Lorsque je l’ai désactivée à partir de Settings > Developer > Network Link Conditioner
, mon problème a été résolu.
J'espère que cela aidera quelqu'un.
J'ai rencontré le même problème lors de l'appel via le serveur de mon entreprise à partir de l'application iOS 12 avec un périphérique physique. Le problème était que le disque dur du serveur était plein. Libérer de l'espace sur le serveur a résolu le problème.
J'ai trouvé la même erreur dans une autre situation qui, à mon avis, était due à un délai d'attente non paramétrable via l'API réseau fournie par Apple (URLSession.timeoutIntervalForRequest
et URLSession.timeoutIntervalForResource
). Même là .. réponse du serveur plus rapide a résolu le problème
Sur 2017-01-25
, Apple a publié un Q & A technique concernant cette erreur:
Questions techniques Apple QA1941
Traitement des erreurs "La connexion réseau a été perdue"
A: NSURLErrorNetworkConnectionLost correspond à l'erreur -1005 dans le domaine d'erreur NSURLErrorDomain et s'affiche pour les utilisateurs sous le nom «La connexion réseau a été perdue». Cette erreur signifie que la connexion TCP sous-jacente qui achemine la demande HTTP 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 automatiquement ces demandes (en particulier si la demande est idempotente), mais dans d’autres circonstances, cela n’est pas autorisé par les normes HTTP.
https://developer.Apple.com/library/archive/qa/qa1941/_index.html#//Apple_ref/doc/uid/DTS40017602