Dominio errore = Codice NSURLErrorDomain = -1005 "La connessione di rete è stata persa."

Ho un'applicazione che funziona bene su Xcode6-Beta1 e Xcode6-Beta2 sia con iOS7 che iOS8. Ma con Xcode6-Beta3, Beta4, Beta5 sto affrontando problemi di rete con iOS8 ma tutto funziona perfettamente su iOS7. Ottengo l'errore "The network connection was lost.". L'errore è il seguente:

Errore: Errore Dominio = Codice NSURLErrorDomain = -1005 "La connessione di rete è stata persa." UserInfo = 0x7ba8e5b0 {NSErrorFailingURLStringKey =, _kCFStreamErrorCodeKey = 57, NSErrorFailingURLKey =, NSLocalizedDescription = La connessione di rete è stata persa., _KCFStreamErrorDomainKey = 1, NSUn0 "0)

Uso AFNetworking 2.xe il seguente frammento di codice per effettuare la chiamata di rete:

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

Ho provato NSURLSessionma continuo a ricevere lo stesso errore.

Il riavvio del simulatore ha risolto il problema per me.

Abbiamo riscontrato questo errore esatto e si è rivelato un problema con l'implementazione HTTP sottostante di NSURLRequest:

Per quanto possiamo dire, quando iOS 8/10/10/11 riceve una risposta HTTP con Keep-Aliveun'intestazione, mantiene questa connessione per riutilizzarla in seguito (come dovrebbe), ma la mantiene per più del timeoutparametro del Intestazione Keep-Alive (sembra mantenere sempre attiva la connessione per 30 secondi.) Quindi quando una seconda richiesta viene inviata dall'app meno di 30 secondi dopo, tenta di riutilizzare una connessione che potrebbe essere stata interrotta dal server (se Keep-Aliveè trascorso più del reale ).

Ecco le soluzioni che abbiamo trovato finora:

• Aumentare il parametro di timeout del server oltre i 30 secondi. Sembra che iOS si comporti sempre come se il server manterrà la connessione aperta per 30 secondi indipendentemente dal valore fornito nell'intestazione Keep-Alive. (Questo può essere fatto per Apache impostando l' KeepAliveTimeoutopzione.
• Puoi semplicemente disabilitare il meccanismo keep alive per i client iOS in base all'utente-agente della tua app (ad es. Per Apache: BrowserMatch "iOS 8\." nokeepalivenel file mod setenvif.conf)
• Se non hai accesso al server, puoi provare a inviare le tue richieste con Connection: closeun'intestazione: questo dirà al server di abbandonare immediatamente la connessione e di rispondere senza mantenere le intestazioni in vita. MA al momento, NSURLSession sembra sovrascrivere l' Connectionintestazione quando vengono inviate le richieste (non abbiamo testato ampiamente questa soluzione in quanto possiamo modificare la configurazione di Apache)

Per il mio, Resetting content and settingsdi Simulator funziona. Per ripristinare il simulatore seguire i passaggi:

Simulatore iOS -> Reimposta contenuto e impostazioni -> Premi Reimposta (sull'avviso che verrà)

Il runtime del simulatore iOS 8.0 presenta un bug per cui se la configurazione della rete cambia durante l'avvio del dispositivo simulato, le API di livello superiore (ad es. CFNetwork) nel runtime simulato penseranno che abbia perso la connettività di rete. Attualmente, la soluzione consigliata è semplicemente riavviare il dispositivo simulato quando cambia la configurazione della rete.

Se sei interessato da questo problema, ti preghiamo di presentare ulteriori radar duplicati su http://bugreport.apple.com per ottenere una maggiore priorità.

Se si riscontra questo problema senza aver modificato le configurazioni di rete, non si tratta di un bug noto e si dovrebbe sicuramente presentare un radar, indicando che il problema non è il bug noto modificato nella configurazione di rete.

ciò che ha risolto il problema per me è stato il riavvio del simulatore e il ripristino del contenuto e delle impostazioni.

Inoltre, si verifica un problema con beta 5 e AFNetworking 1.3 durante l'esecuzione sul simulatore iOS 8 che provoca un errore di connessione:

Dominio = Codice NSURLErrorDomain = -1005 "La connessione di rete è stata persa."

Lo stesso codice funziona bene sui simulatori iOS 7 e 7.1 e il mio proxy di debug mostra che l'errore si verifica prima che venga effettivamente tentata una connessione (ovvero nessuna richiesta registrata).

Ho rintracciato l'errore su NSURLConnection e segnalato bug ad Apple. Vedi riga 5 nell'immagine allegata:

.

La modifica all'utilizzo httpsconsente la connessione dai simulatori di iOS 8 sebbene con errori intermittenti.

Il problema è ancora presente in Xcode 6.01 (gm).

Ho riscontrato questo problema durante l'utilizzo di Alamofire. Il mio errore era che stavo inviando un dizionario vuoto [:]per i parametri su una GETrichiesta, piuttosto che inviare nilparametri.

Spero che questo ti aiuti!

L'apertura di Charles ha risolto il problema per me, il che sembra molto strano ...

Charles è un proxy HTTP / monitor HTTP / proxy inverso che consente a uno sviluppatore di visualizzare tutto il traffico HTTP e SSL / HTTPS tra la propria macchina e Internet. Ciò include le richieste, le risposte e le intestazioni HTTP (che contengono i cookie e le informazioni di memorizzazione nella cache).

Vedi il commento di Pjebs il 5 gennaio su Github.

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

Alcuni suggeriscono anche di riconnettersi al sito,

vale a dire licenziare la richiesta POST DUE VOLTE

Soluzione: utilizzare un metodo per eseguire la connessione al sito, return (id), se la connessione di rete è stata persa, tornare a utilizzare lo stesso metodo.

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

}

Stavo ottenendo anche questo errore, ma su dispositivi reali piuttosto che sul simulatore. Abbiamo notato l'errore quando si accede al nostro back-end heroku su HTTPS (server gunicorn) e si eseguono POSTS con bodys di grandi dimensioni (qualsiasi cosa superiore a 64 KB). Usiamo HTTP Basic Auth per l'autenticazione e abbiamo notato che l'errore è stato risolto NON utilizzando il didReceiveChallenge:metodo delegato su NSURLSession, ma piuttosto inserendo l'autenticazione nell'intestazione della richiesta originale tramite l'aggiunta Authentiation: Basic <Base64Encoded UserName:Password>. Ciò impedisce al 401 necessario di attivare il didReceiveChallenge:messaggio delegato e la successiva connessione di rete persa.

Ho avuto lo stesso problema. Soluzione era semplice, ho impostato HTTPBody, ma non è stato impostato HTTPMethoda POST. Dopo aver risolto questo, tutto andava bene.

Ho avuto lo stesso problema. Non so come AFNetworking implementa la richiesta https, ma il motivo per me è il problema di cache di NSURLSession.

Dopo che la mia applicazione è tornata da Safari e quindi ha inviato una richiesta http, apparirà l'errore "Caricamento http fallito 1005". Se smetto di usare "[NSURLSession sharedSession]", ma per usare un'istanza NSURLSession configurabile per chiamare il metodo "dataTaskWithRequest:" come segue, il problema è risolto.

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

Ricorda solo di impostare config.URLCache = nil;.

Ho dovuto uscire da XCode, eliminare il contenuto della cartella DerivedData (~ / Library / Developer / Xcode / DerivedData o / Library / Developer / Xcode / DerivedData) ed uscire dal simulatore per farlo funzionare.

Ho anche questo problema, in esecuzione su un dispositivo iOS 8. È dettagliato un po 'di più qui e sembra essere un caso di iOS che tenta di utilizzare connessioni che sono già scadute. Il mio problema non è lo stesso del problema Keep-Alive spiegato in quel link, tuttavia sembra essere lo stesso risultato finale.

Ho corretto il mio problema eseguendo un blocco ricorsivo ogni volta che ricevo un errore -1005 e questo fa sì che la connessione alla fine riesca anche se a volte la ricorsione può eseguire il ciclo per più di 100 volte prima che la connessione funzioni, tuttavia aggiunge solo un secondo in esecuzione volte e scommetto che è solo il tempo impiegato dal debugger per stampare il NSLog per me.

Ecco come eseguo un blocco ricorsivo con AFNetworking: aggiungi questo codice al file della classe di connessione

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

Quindi usalo come questo:

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

Vedrai che uso a AFHTTPRequestOperation sottoclasse ma aggiungo il tuo codice di richiesta. La parte importante è la chiamata recurse(@offset.intValue+1));per richiamare nuovamente il blocco.

Se il problema si verifica su un dispositivo, controlla se il traffico passa attraverso un proxy (Impostazioni> Wi-Fi> (informazioni)> Proxy HTTP). Ho avuto il mio dispositivo configurato per l'uso con Charles, ma ho dimenticato il proxy. Sembra che senza Charles si stia effettivamente eseguendo questo errore.

Se qualcuno riceve questo errore durante il caricamento di file su un server back-end, assicurarsi che il server di ricezione abbia una dimensione massima del contenuto consentita per i file multimediali. Nel mio caso, NGINX ha richiesto un valore superiore client_max_body_size. NGINX rifiuta la richiesta prima che il caricamento sia terminato, quindi non viene restituito alcun codice di errore.

Stavo ottenendo l'errore su un dispositivo iOS 7 quando stavo usando Xcode 6.2 beta.

Il passaggio da Xcode 6.2 beta a 6.1.1 ha risolto il problema, almeno su un dispositivo iOS 7.

Su 2017-01-25Apple sono state rilasciate domande e risposte tecniche relative a questo errore:

Domande e risposte tecniche di Apple QA1941

Gestione degli errori "La connessione di rete è stata persa"

A: NSURLErrorNetworkConnectionLost è errore -1005 nel dominio di errore NSURLErrorDomain e viene visualizzato dagli utenti come "La connessione di rete è stata persa". Questo errore indica che la connessione TCP sottostante che trasporta la richiesta HTTP è stata disconnessa mentre era in corso la richiesta HTTP (vedi sotto per maggiori informazioni a riguardo). In alcune circostanze NSURLSession può ritentare automaticamente tali richieste (in particolare, se la richiesta è idempotente) ma in altre circostanze ciò non è consentito dagli standard HTTP.

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

Ho riscontrato il problema per mesi e finalmente ho scoperto che quando disabilitavamo DNSSEC sul nostro dominio api, tutto era ok: simple_smile:

Mi stavo connettendo tramite una VPN. La disabilitazione della VPN ha risolto il problema.

Ho riscontrato questo errore durante il passaggio di una richiesta NSURL a una sessione NSURL senza impostare il metodo HTTP della richiesta .

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

Dominio errore = Codice NSURLErrorDomain = -1005 "La connessione di rete è stata persa."

Aggiungi HTTPMethodperò, e la connessione funziona bene

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

Verifica se puoi richiedere da altre app (come Safari). Altrimenti potrebbe essere qualcosa sul tuo computer. Nel mio caso ho avuto questo problema con Avast Antivirus, che stava bloccando la mia richiesta di simulatori (non chiedermi perché).

Il riavvio del computer ha risolto il problema con Xcode9.1. Avevo riavviato il simulatore e Xcode, non funziona.

Stavo affrontando lo stesso problema, ho abilitato Network Link Conditioner per i test di rete lenti per l'app. Questo stava creando questo errore alcune volte, quando l'ho disabilitato Settings > Developer > Network Link Conditioner, ha risolto il mio problema.

Spero che questo aiuti qualcuno.

In cima a tutte le risposte ho trovato una bella soluzione. In realtà il problema relativo alla connessione di rete non riesce per onword iOS 12 è perché c'è un bug nell'onword 12.0 iOS. Eppure da risolvere. Avevo attraversato la community di git hub per il problema relativo a AFNetworking quando l'app proveniva da background e cercava di effettuare chiamate di rete e non riusciva a stabilire la connessione. Trascorro 3 giorni su questo e cerco molte cose per arrivare alla causa principale e non ho trovato nulla. Finalmente ho avuto un po 'di luce nell'oscurità quando ho rosso questo blog https://github.com/AFNetworking/AFNetworking/issues/4279

Sta dicendo che c'è un bug in iOS 12. Fondamentalmente non puoi aspettarti che una chiamata di rete venga mai completata se l'app non è in primo piano. E a causa di questo errore, le chiamate di rete vengono eliminate e si verifica un errore di rete nei registri.

Il mio miglior suggerimento per te è di fornire qualche ritardo quando l'app passa dallo sfondo al primo piano e c'è una chiamata di rete. Effettua la chiamata di rete nella spedizione asincrona con un certo ritardo. Non si verificherà mai la caduta delle chiamate di rete o la perdita di connessione.

Non aspettare che Apple risolva questo problema per iOS 12 perché è ancora da risolvere. Puoi risolvere questo problema fornendo un ritardo per la tua richiesta di rete come NSURLConnection, NSURLSession o AFNetworking o ALAMOFIRE. Saluti :)

Nel mio caso è stato perché mi stavo connettendo a HTTP ed era in esecuzione su HTTPS

Ho riscontrato questo problema per il seguente motivo.

TLDR: verifica se stai inviando una GETrichiesta che dovrebbe inviare i parametri sull'URL anziché sulla NSURLRequest's HTTBodyproprietà.

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

Avevo montato un'astrazione di rete sulla mia app e funzionava abbastanza bene per tutte le mie richieste.

Ho aggiunto una nuova richiesta a un altro servizio Web (non mio) e ha iniziato a farmi questo errore.

Sono andato in un parco giochi e ho iniziato da zero costruendo una richiesta di barebone, e ha funzionato. Così ho iniziato ad avvicinarmi alla mia astrazione fino a quando non ho trovato la causa.

La mia implementazione dell'astrazione aveva un bug: stavo inviando una richiesta che avrebbe dovuto inviare parametri codificati nell'URL e stavo anche riempiendo la NSURLRequest's HTTBodyproprietà con i parametri della query. Non appena l'ho rimosso HTTPBodyha funzionato.

Stavo ricevendo questo errore e ho anche notato che anche l'applicazione Postman stava cadendo ma funzionava nell'app Advanced Rest Client (ARC) e funzionava in Android. Quindi ho dovuto installare Charles per eseguire il debug della comunicazione e ho notato che il codice di risposta era -1. Il problema era che il programmatore REST ha dimenticato di restituire il codice di risposta 200.

Spero che questo aiuti altri sviluppatori.

Ogni volta che viene visualizzato l'errore -1005, è necessario chiamare nuovamente 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... 
       }
  }];

È necessario aggiungere il codice per chiamare nuovamente la funzione. Assicurati di essere stato chiamato metodo una volta altrimenti il ​​suo ciclo ricorsivo di chiamata.

Ho riscontrato lo stesso problema durante la chiamata utilizzando il server della mia azienda dall'app iOS 12 con un dispositivo fisico. Il problema era che il disco rigido del server era pieno. Liberare spazio nel server ha risolto il problema.

Ho riscontrato lo stesso errore in un'altra situazione che penso a causa di un timeout non parametrizzabile tramite l'API di rete standard fornita da Apple ( URLSession.timeoutIntervalForRequeste URLSession.timeoutIntervalForResource). Anche lì .. reso più veloce la risposta del server risolto il problema