Error Domain = NSURLErrorDomain Code = -1005 "Se perdió la conexión de red".

Tengo una aplicación que funciona bien en Xcode6-Beta1 y Xcode6-Beta2 con iOS7 e iOS8. Pero con Xcode6-Beta3, Beta4, Beta5, tengo problemas de red con iOS8, pero todo funciona bien en iOS7. Me sale el error "The network connection was lost.". El error es el siguiente:

Error: Error Domain = NSURLErrorDomain Code = -1005 "Se perdió la conexión de red". UserInfo = 0x7ba8e5b0 {NSErrorFailingURLStringKey =, _kCFStreamErrorCodeKey = 57, NSErrorFailingURLKey =, NSLocalizedDescription = La conexión de red se perdió., _KCFStreamErrorDomainKey = 1, NSUnderlyingError = 069 ".

Utilizo AFNetworking 2.xy el siguiente fragmento de código para realizar la llamada de red:

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

Lo intenté NSURLSessionpero sigo recibiendo el mismo error.

Reiniciar el simulador me solucionó el problema.

Tuvimos este error exacto y resultó ser un problema con la implementación HTTP subyacente de NSURLRequest:

Por lo que podemos decir, cuando iOS 8/9/10/11 recibe una respuesta HTTP con un Keep-Aliveencabezado, mantiene esta conexión para reutilizarla más tarde (como debería), pero la mantiene durante más tiempo que el timeoutparámetro Encabezado Keep-Alive (parece que siempre mantiene la conexión activa durante 30 segundos). Luego, cuando la aplicación envía una segunda solicitud menos de 30 segundos después, intenta reutilizar una conexión que el servidor podría haber caído. (si Keep-Aliveha transcurrido más de lo real ).

Aquí están las soluciones que hemos encontrado hasta ahora:

• Aumente el parámetro de tiempo de espera del servidor por encima de 30 segundos. Parece que iOS siempre se comporta como si el servidor mantuviera la conexión abierta durante 30 segundos, independientemente del valor proporcionado en el encabezado Keep-Alive. (Esto se puede hacer para Apache configurando la KeepAliveTimeoutopción.
• Simplemente puede deshabilitar el mecanismo Keep Live para clientes iOS basado en el User-Agent de su aplicación (por ejemplo, para Apache: BrowserMatch "iOS 8\." nokeepaliveen el archivo mod setenvif.conf)
• Si no tiene acceso al servidor, puede intentar enviar sus solicitudes con un Connection: closeencabezado: esto le indicará al servidor que desconecte la conexión de inmediato y que responda sin ningún encabezado de mantener vivo. PERO en este momento, NSURLSession parece anular el Connectionencabezado cuando se envían las solicitudes (no probamos esta solución ampliamente, ya que podemos modificar la configuración de Apache)

Para el mío, Resetting content and settingsde Simulator funciona. Para restablecer el simulador, siga los pasos:

Simulador de iOS -> Restablecer contenido y configuración -> Presione Restablecer (en la advertencia que vendrá)

El tiempo de ejecución del simulador de iOS 8.0 tiene un error por el cual si la configuración de su red cambia mientras se inicia el dispositivo simulado, las API de nivel superior (por ejemplo: CFNetwork) en el tiempo de ejecución simulado pensarán que ha perdido la conectividad de la red. Actualmente, la solución recomendada es simplemente reiniciar el dispositivo simulado cuando cambia la configuración de su red.

Si se ve afectado por este problema, presente radares duplicados adicionales en http://bugreport.apple.com para obtener una mayor prioridad.

Si ve este problema sin haber cambiado las configuraciones de red, entonces ese no es un error conocido, y definitivamente debe archivar un radar, lo que indica que el problema no es el error conocido de cambio de configuración de red.

Lo que resolvió el problema para mí fue reiniciar el simulador y restablecer el contenido y la configuración.

También tenga un problema con beta 5 y AFNetworking 1.3 cuando se ejecuta en el simulador de iOS 8 que produce un error de conexión:

Domain = NSURLErrorDomain Code = -1005 "Se perdió la conexión de red".

El mismo código funciona bien en los simuladores de iOS 7 y 7.1 y mi proxy de depuración muestra que la falla ocurre antes de que se intente realmente una conexión (es decir, no se registran solicitudes).

He rastreado la falla de NSURLConnection y reporté un error a Apple. Ver línea 5 en la imagen adjunta:

.

El cambio de uso httpspermite la conexión desde simuladores de iOS 8 aunque con errores intermitentes.

El problema aún está presente en Xcode 6.01 (gm).

Estaba experimentando este problema mientras usaba Alamofire. Mi error fue que estaba enviando un diccionario vacío [:]para los parámetros en una GETsolicitud, en lugar de enviar nilparámetros.

¡Espero que esto ayude!

Abrir Charles resolvió el problema para mí, lo que parece muy extraño ...

Charles es un proxy HTTP / monitor HTTP / Proxy inverso que permite a un desarrollador ver todo el tráfico HTTP y SSL / HTTPS entre su máquina e Internet. Esto incluye solicitudes, respuestas y los encabezados HTTP (que contienen las cookies y la información de almacenamiento en caché).

Vea el comentario de pjebs el 5 de enero en Github.

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

También algunos sugieren volver a conectarse al sitio,

es decir, disparando la solicitud POST DOS VECES

Solución: use un método para conectarse al sitio, return (id), si se perdió la conexión de red, vuelva a usar el mismo método.

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

}

También recibí este error, pero en dispositivos reales en lugar del simulador. Notamos el error al acceder a nuestro backend heroku en HTTPS (servidor gunicorn), y al hacer POSTS con grandes cuerpos (cualquier cosa de más de 64Kb). Utilizamos la autenticación básica HTTP para la autenticación, y notamos que el error se resolvió al NO usar el didReceiveChallenge:método delegado en NSURLSession, sino al incorporar la autenticación en el encabezado de la solicitud original mediante la adición Authentiation: Basic <Base64Encoded UserName:Password>. Esto evita que el 401 necesario active el didReceiveChallenge:mensaje de delegado y se pierda la conexión de red posterior.

Tuve el mismo problema Solución era simple, lo he instalado HTTPBody, pero no he puesto HTTPMethoda POST. Después de arreglar esto, todo estuvo bien.

Yo tuve el mismo problema. No sé cómo AFNetworking implementa la solicitud https, pero la razón para mí es el problema de caché de NSURLSession.

Después de que mi aplicación realice un seguimiento desde Safari y luego publique una solicitud http, aparecerá el error "Error de carga http 1005". Si dejo de usar "[NSURLSession sharedSession]", pero para usar una instancia de NSURLSession configurable para llamar al método "dataTaskWithRequest:" de la siguiente manera, el problema está resuelto.

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

Solo recuerda configurar config.URLCache = nil;.

Tuve que salir de XCode, eliminar el contenido de la carpeta DerivedData (~ / Library / Developer / Xcode / DerivedData o / Library / Developer / Xcode / DerivedData) y salir del simulador para que esto funcione.

También tengo este problema, ejecutándose en un dispositivo iOS 8. Aquí se detalla un poco más y parece ser un caso de iOS tratando de usar conexiones que ya han expirado. Mi problema no es el mismo que el problema Keep-Alive explicado en ese enlace, sin embargo, parece ser el mismo resultado final.

He corregido mi problema ejecutando un bloque recursivo cada vez que recibo un error -1005 y esto hace que la conexión finalmente se complete, aunque a veces la recursión puede repetirse más de 100 veces antes de que la conexión funcione, sin embargo, solo agrega un segundo segundo en ejecución veces y apuesto a que ese es el tiempo que le toma al depurador imprimir los NSLog para mí.

Así es como ejecuto un bloque recursivo con AFNetworking: agregue este código a su archivo de clase de conexión

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

Entonces úsalo así:

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

Verá que uso una AFHTTPRequestOperationsubclase pero agrego su propio código de solicitud. La parte importante es llamar recurse(@offset.intValue+1));para que el bloque se vuelva a llamar.

Si el problema ocurre en un dispositivo, verifique si el tráfico pasa por un proxy (Configuración> Wi-Fi> (información)> Proxy HTTP). Tenía la configuración de mi dispositivo para usar con Charles, pero olvidé el proxy. Parece que sin Charles realmente ejecutando este error se produce.

Si alguien recibe este error al cargar archivos en un servidor de fondo, asegúrese de que el servidor receptor tenga un tamaño de contenido máximo que sea permitido para sus medios. En mi caso, NGINX requirió una mayor client_max_body_size. NGINX rechazaría la solicitud antes de que se realizara la carga, por lo que no volvió ningún código de error.

Recibí el error en un dispositivo iOS 7 cuando estaba usando Xcode 6.2 beta.

Cambiar de Xcode 6.2 beta a 6.1.1 solucionó el problema, al menos en un dispositivo iOS 7.

En 2017-01-25Apple lanzó un Q&A técnico con respecto a este error:

Preguntas y respuestas técnicas de Apple QA1941

Manejo de errores "Se perdió la conexión de red"

R: NSURLErrorNetworkConnectionLost es el error -1005 en el dominio de error NSURLErrorDomain, y se muestra a los usuarios como "Se perdió la conexión de red". Este error significa que la conexión TCP subyacente que lleva la solicitud HTTP se desconectó mientras la solicitud HTTP estaba en curso (consulte a continuación para obtener más información al respecto). En algunas circunstancias, NSURLSession puede volver a intentar dichas solicitudes automáticamente (específicamente, si la solicitud es idempotente), pero en otras circunstancias eso no está permitido por los estándares HTTP.

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

Tuve el problema durante meses y finalmente descubrí que cuando deshabilitamos DNSSEC en nuestro dominio de API, todo estaba bien: simple_smile:

Me estaba conectando a través de una VPN. Deshabilitar la VPN resolvió el problema.

Estaba detectando este error al pasar una NSURLRequest a una NSURLSession sin configurar el HTTPMethod de la solicitud .

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

Error Domain = NSURLErrorDomain Code = -1005 "Se perdió la conexión de red".

Agregue HTTPMethod, sin embargo, y la conexión funciona bien

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

Pruebe si puede solicitarlo desde otras aplicaciones (como safari). Si no, podría ser algo en su computadora. En mi caso, tuve este problema con Avast Antivirus, que estaba bloqueando mi solicitud de simuladores (no me pregunten por qué).

Reiniciar la computadora me solucionó el problema con Xcode9.1. Había reiniciado el simulador y Xcode, no funciona.

Estaba enfrentando el mismo problema, he habilitado el Acondicionador de enlace de red para pruebas de red lentas para la aplicación. Eso estaba creando este error algunas veces, cuando lo desactivé Settings > Developer > Network Link Conditioner, resolvió mi problema.

Espero que esto ayude a alguien.

Además de todas las respuestas, encontré una buena solución. En realidad, el problema relacionado con la conexión de red falla para iOS 12 onword es porque hay un error en iOS 12.0 onword. Y aún no se ha resuelto. Había pasado por la comunidad de git hub por un problema relacionado con AFNetworking cuando la aplicación vino de fondo e intenta hacer llamadas de red y falla al establecer la conexión. Paso 3 días en esto e intento muchas cosas para llegar a la causa raíz de esto y no encontré nada. Finalmente obtuve un poco de luz en la oscuridad cuando leí este blog https://github.com/AFNetworking/AFNetworking/issues/4279

Está diciendo que hay un error en el iOS 12. Básicamente, no puede esperar que se complete una llamada de red si la aplicación no está en primer plano. Y debido a este error, las llamadas de la red se cortan y la red falla en los registros.

Mi mejor sugerencia para usted es proporcionar un retraso cuando su aplicación esté en segundo plano y haya una llamada de red. Realice esa llamada de red en el despacho asíncrono con cierto retraso. Nunca obtendrá la caída de llamadas de red o pérdida de conexión

No espere a que Apple permita que este problema se resuelva para iOS 12, ya que aún no se ha solucionado. Puede optar por esta solución al proporcionar un retraso para su solicitud de red, ya sea NSURLConnection, NSURLSession o AFNetworking o ALAMOFIRE. Salud :)

En mi caso fue porque me estaba conectando a HTTP y se estaba ejecutando en HTTPS

Estaba teniendo este problema por la siguiente razón.

TLDR: compruebe si está enviando una GETsolicitud que debería enviar los parámetros en la URL en lugar de en la NSURLRequest's HTTBodypropiedad.

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

Había montado una abstracción de red en mi aplicación, y estaba funcionando bastante bien para todas mis solicitudes.

Agregué una nueva solicitud a otro servicio web (no el mío) y comenzó a arrojarme este error.

Fui a un patio de juegos y comencé desde cero construyendo una solicitud básica, y funcionó. Entonces comencé a acercarme a mi abstracción hasta que encontré la causa.

Mi implementación de abstracción tenía un error: estaba enviando una solicitud que debía enviar parámetros codificados en la url y también estaba llenando la NSURLRequest's HTTBodypropiedad con los parámetros de consulta. Tan pronto como lo quité HTTPBody, funcionó.

Recibí este error y también me di cuenta de que la aplicación Postman también estaba cayendo, pero estaba trabajando en la aplicación Advanced Rest Client (ARC) y en Android. Así que tuve que instalar Charles para depurar la comunicación y me di cuenta de que el código de respuesta era -1. El problema fue que el programador REST olvidó devolver el código de respuesta 200.

Espero que esto ayude a otros desarrolladores.

Siempre que tenga el error -1005, entonces deberá llamar a API nuevamente.

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

Debe agregar su código para llamar a la función nuevamente. Asegúrese de que haya sido llamado método una vez, de lo contrario, es un ciclo recursivo de llamada.

Enfrenté el mismo problema al llamar usando el servidor de mi empresa desde la aplicación iOS 12 con un dispositivo físico. El problema era que el disco duro del servidor estaba lleno. Liberar espacio en el servidor resolvió el problema.

Encontré el mismo error en otra situación, creo que debido a un tiempo de espera no parametrizable a través de la API de red estándar proporcionada por Apple ( URLSession.timeoutIntervalForRequesty URLSession.timeoutIntervalForResource). Incluso allí ... hizo que el servidor respondiera más rápido resolvió el problema