ios8 - programming - xcode online

Error de dominio=NSURLErrorDomain Code=-1005 "La conexión de red se perdió". (27)

Tengo una aplicación que funciona bien en Xcode6-Beta1 y Xcode6-Beta2 con iOS7 y iOS8. Pero con Xcode6-Beta3, Beta4, Beta5, me enfrento a 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 de dominio = NSURLErrorDomain Code = -1005 "Se perdió la conexión de red." UserInfo = 0x7ba8e5b0 {NSErrorFailingURLStringKey =, _kCFStreamErrorCodeKey = 57, NSErrorFailingURLKey =, NSLocalizedDescription = Se perdió la conexión de la red.

Uso AFNetworking 2.xy el siguiente fragmento de código para hacer 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); }];

Intenté NSURLSession pero todavía recibo el mismo error.

Cada vez que se obtiene el error -1005, es necesario volver a llamar a la API.

Necesita agregar su código para llamar a la función de nuevo. Asegúrese de que era el método de llamada una vez, de lo contrario, su ciclo recursivo de llamada.

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

El reinicio de la computadora solucionó el problema para mí con Xcode9.1. Había reiniciado el simulador y Xcode, no funciona.

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 alternativa recomendada es simplemente reiniciar el dispositivo simulado cuando cambie la configuración de la red.

Si está 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 la 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 en la configuración de la red.

Encima 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 la versión iOS 12.0 onword. Y aún está por resolver. Había pasado por la comunidad de git hub por un problema relacionado con AFNetworking cuando la aplicación provenía de un segundo plano e intentaba hacer una llamada de red y fallaba en el establecimiento de la conexión. Pasé 3 días en esto e intenté muchas cosas para llegar a la causa raíz de esto y no encontré nada. Finalmente obtuve algo de luz en la oscuridad cuando escribí 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 una llamada de la red se complete si la aplicación no está en primer plano. Y debido a este error, las llamadas de red se eliminan y obtenemos errores de red en los registros.

Mi mejor sugerencia para usted es proporcionar cierta demora cuando su aplicación viene del fondo al primer plano y hay una llamada de red. Hacer esa llamada de red en el despacho asíncrono con un cierto retraso. Nunca obtendrás caída de llamadas de red o pérdida de conexión.

No espere a que Apple deje que este problema se resuelva para iOS 12 ya que todavía no se ha solucionado. Puede ir con esta solución proporcionando un retraso para su solicitud de red como NSURLConnection, NSURLSession o AFNetworking o ALAMOFIRE. Saludos :)

Estaba cometiendo este error al pasar una solicitud NSURL a una sesión NSURLS sin configurar el método HTTP de la solicitud .

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

Error de dominio = NSURLErrorDomain Code = -1005 "La conexión de red se perdió."

Agrega el HTTPMethod , sin embargo, y la conexión funciona bien

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

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

¡Espero que esto ayude!

Estaba recibiendo el error incluso en el dispositivo ios7 cuando estaba usando xcode 6.2 beta. el cambio de xcode 6.2 beta a 6.1.1 solucionó el problema. al menos en el dispositivo ios7.

Estaba teniendo este problema por la siguiente razón.

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

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

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 (que no es el mío) y comenzó a enviarme este error.

Fui a un patio de recreo y comencé desde cero construyendo una solicitud de barebones, y funcionó. Así que empecé 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 propiedad NSURLRequest''s HTTBody con los parámetros de consulta también. Tan pronto como quité el HTTPBody funcionó.

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

Lo que me solucionó el problema fue reiniciar el simulador y restablecer el contenido y la configuración.

Me enfrentaba al mismo problema, he habilitado el Acondicionador de enlace de red para realizar pruebas lentas de red para la aplicación. Eso fue crear este error algunas veces. Cuando lo deshabilité en Settings > Developer > Network Link Conditioner , resolví mi problema.

Espero que esto ayude a alguien.

Me estaba conectando a través de una VPN. Desactivar la VPN solucionó el problema.

Para el mío, Resetting content and settings del simulador funciona. Para reiniciar el simulador sigue los pasos:

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

Prueba si puedes solicitar desde otras aplicaciones (como safari). Si no puede ser algo en su computadora. En mi caso tuve este problema con Avast Antivirus, que estaba bloqueando la solicitud de mis simuladores (no me pregunte por qué).

Recibí este error y también se da cuenta de que la aplicación Postman también se 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 noté 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.

Reiniciar el simulador solucionó el problema para mí.

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

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 me olvidé del proxy. Parece que sin Charles realmente se ejecuta este error.

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

También tengo este problema, corriendo en un dispositivo iOS 8. Se detalla un poco más aquí y parece ser un caso de iOS que intenta 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 termine 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 al proceso veces y apuesto a que es justo el tiempo que tarda el depurador en imprimir los NSLog''s 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 como este:

+ (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ás que uso una subclase AFHTTPRequestOperation pero agrego tu propio código de solicitud. La parte importante es llamar a recurse(@offset.intValue+1)); Para hacer que el bloque vuelva a ser llamado.

También tiene un problema con beta 5 y AFNetworking 1.3 cuando se ejecuta en el simulador iOS8 que produce un error de conexión "Dominio = NSURLErrorDomain Code = -1005" Se perdió la conexión de red. "". El mismo código funciona bien en los simuladores iOS7 y 7.1 y mi proxy de depuración muestra que la falla se produce antes de que se intente una conexión (es decir, no se registra ninguna solicitud). He rastreado la falla de NSURLConnection y reporté un error a Apple. Ver adjunto línea 5 en imagen adjunta. . Cambiar a usar https permite la conexión desde simuladores iOS8 aunque con errores intermitentes. El problema todavía está presente en Xcode 6.01 (gm).

Tuve el mismo problema La solución fue simple, configuré HTTPBody , pero no configuré HTTPMethod en POST . Después de arreglar esto, todo estaba bien.

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 hacer que esto funcione.

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 encabezado Keep-Alive , mantiene esta conexión para reutilizarla más tarde (como debería), pero la mantiene por más que la parámetro de timeout de timeout del 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 podría haber sido soltado por el servidor (si ha transcurrido más del real Keep-Alive ).

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 opción KeepAliveTimeout .
Simplemente puede deshabilitar el mecanismo de mantener vivo para los clientes de iOS en función del User-Agent de su aplicación (por ejemplo, para Apache: BrowserMatch "iOS 8/." nokeepalive en el archivo mod setenvif.conf )
Si no tiene acceso al servidor, puede intentar enviar sus solicitudes con una Connection: close encabezado: esto le indicará al servidor que interrumpa la conexión de inmediato y responda sin ningún tipo de encabezados. PERO en este momento, NSURLSession parece anular el encabezado de Connection cuando se envían las solicitudes (no probamos esta solución exhaustivamente, ya que podemos modificar la configuración de Apache)

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 vuelva de safari y luego publique una solicitud http, aparecerá el error "http load failed 1005". Si dejé de usar "[NSURLSession sharedSession]" , pero al usar una instancia configurable de NSURLSession para llamar al método "dataTaskWithRequest:" como sigue, se soluciona el problema.

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

Solo recuerda configurar config.URLCache = nil; .

Ver 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 hacer la conexión 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; } }