Domínio de erro = Código NSURLErrorDomain = -1005 "A conexão de rede foi perdida."


268

Eu tenho um aplicativo que funciona bem no Xcode6-Beta1 e Xcode6-Beta2 com iOS7 e iOS8. Mas com o Xcode6-Beta3, Beta4, Beta5, estou enfrentando problemas de rede no iOS8, mas tudo funciona bem no iOS7. Eu recebo o erro "The network connection was lost.". O erro é o seguinte:

Erro: Domínio do erro = Código NSURLErrorDomain = -1005 "A conexão de rede foi perdida." UserInfo = 0x7ba8e5b0 {NSErrorFailingURLStringKey =, _kCFStreamErrorCodeKey = 57, NSErrorFailingURLKey =, NSLocalizedDescription = A conexão de rede foi perdida., _KCFStreamErrorDomainKey = 1, "

Eu uso o AFNetworking 2.xe o seguinte snippet de código para fazer a chamada de rede:

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

Eu tentei, NSURLSessionmas ainda recebo o mesmo erro.


Qualquer atualização ? Isso só acontece no iOS 8 no Wifi para mim, ainda tentando encontrar uma solução alternativa.
Dimillian 23/09/14


Alguém pode me ajudar a resolver o meu problema, quase o mesmo problema, mas o código de erro diferente, stackoverflow.com/questions/26972822/...
iYoung

1
enfrentando o mesmo problema com iOS 10.0.1 e Xcode 8.
Satheeshwaran

1
Recebi esse erro esta manhã e o corrigi agora com uma solução simples e estranha. O endereço do servidor solicitado está incorreto, não há código de status 4xx ou 5xx retornado, ele apenas encontrou esse problema, não sabe qual é exatamente a causa raiz. Portanto, confirme com os desenvolvedores de back-end da sua equipe ou perderá algumas horas com isso.
Itachi

Respostas:


414

Reiniciar o simulador corrigiu o problema para mim.


3
O que acontece se esse problema estiver no dispositivo e não no sim? Tentei reiniciar o dispositivo, ainda o mesmo erro.
Sean Clark

2
@SeanClark: veja a próxima resposta: reiniciar o simulador funciona porque o sistema operacional precisa interromper a conexão inoperante, em vez de tentar reutilizá-los depois que eles foram descartados pelo servidor. Para contornar esse problema, você pode desativar o mecanismo Keep-alive no servidor para os clientes iOS ou, se você não tiver acesso ao servidor, pode simplesmente tentar novamente a mesma solicitação quando ela falhar (a falha deve causar o sistema operacional interrompe a conexão e uma nova é instanciada quando a nova tentativa é enviada).
Arthur

Atualmente, estou usando o Xcode 6.2 e o que resolveu foi clicar no iOS Simulator> Redefinir configurações e conteúdo. Assim que terminei, saí do simulador e reconstruí e executei meu projeto ... tudo funcionou perfeitamente depois.
KingPolygon

Trabalhou para mim redefinir o simulador, mas apenas 10% do tempo. Acabei de adquirir um novo provedor e ele é meio estranho. Isso acontece o tempo todo agora no simulador. Pode ser a rede.
Noobsmcgoobs

1
Redefinir o simulador não funcionou para mim. No entanto, iniciar Charles fez questão de desaparecer. Consulte stackoverflow.com/a/26066764/598057, que sugere o uso de Charles. Muito estranho, mas funciona ...
Stanislav Pankevich 17/05

231

Tivemos esse erro exato e acabou sendo um problema com a implementação HTTP subjacente de NSURLRequest:

Até onde sabemos, quando o iOS 8/9/10/11 recebe uma resposta HTTP com um Keep-Alivecabeçalho, ela mantém essa conexão para reutilizar mais tarde (como deveria), mas a mantém por mais do que o timeoutparâmetro do Cabeçalho Keep-Alive (parece sempre manter a conexão ativa por 30 segundos.) Em seguida, quando uma segunda solicitação é enviada pelo aplicativo menos de 30 segundos depois, ele tenta reutilizar uma conexão que pode ter sido descartada pelo servidor. (se Keep-Alivetiver passado mais do que o real ).

Aqui estão as soluções que encontramos até agora:

  • Aumente o parâmetro de tempo limite do servidor acima de 30 segundos. Parece que o iOS está sempre se comportando como se o servidor mantivesse a conexão aberta por 30 segundos, independentemente do valor fornecido no cabeçalho Keep-Alive. (Isso pode ser feito para o Apache, definindo a KeepAliveTimeoutopção
  • Você pode simplesmente desativar o mecanismo keep alive para clientes iOS com base no User-Agent do seu aplicativo (por exemplo, para Apache: BrowserMatch "iOS 8\." nokeepaliveno arquivo mod setenvif.conf)
  • Se você não tiver acesso ao servidor, poderá tentar enviar suas solicitações com um Connection: closecabeçalho: isso solicitará que o servidor interrompa a conexão imediatamente e responda sem nenhum cabeçalho manter vivo. MAS, no momento, o NSURLSession parece substituir o Connectioncabeçalho quando as solicitações são enviadas (não testamos essa solução extensivamente, pois podemos ajustar a configuração do Apache)

7
Aqui está um projeto de exemplo que demonstra o problema; um relatório de bug também foi enviado à Apple. cl.ly/Xgkl/keep-alive-fail.zip Inicie o projeto, clique no primeiro botão de publicação (parte superior da tela), aguarde 5 segundos, clique nele novamente, erro.
precisa saber é o seguinte

5
Manter vivo é bilateral. Os clientes adicionarão um cabeçalho http "Conexão: Manter ativo" por padrão, adicionar parâmetros de manter ativo nas solicitações do cliente pode ajudar; por exemplo, "Manter vivo: max = 1". O comentário de Arthur é muito útil, mas também indica mais de um problema na rede do simulador iOS8. Preciso usar https para obter uma conexão, pois o http falha antes de enviar uma solicitação.
ptc

5
Ei pessoal, estou tendo exatamente o mesmo problema no dispositivo. Existe uma correção para isso? Não há nenhum problema no iOS 7.
Andres C

9
Dica: você pode usar a NSURLErrorNetworkConnectionLostconstante em vez de codificar -1005.
Vincent Tourraine

6
Esse problema ainda está presente no iOS 11.2.6.
Makalele

47

Para o meu, Resetting content and settingsdo Simulator funciona. Para redefinir o simulador, siga as etapas:

iOS Simulator -> Redefinir conteúdo e configurações -> Pressione Redefinir (no aviso que virá)


29

O tempo de execução do simulador do iOS 8.0 possui um erro no qual, se a configuração da rede mudar enquanto o dispositivo simulado é inicializado, as APIs de nível superior (por exemplo: CFNetwork) no tempo de execução simulado pensam que perderam a conectividade de rede. Atualmente, a solução recomendada é simplesmente reiniciar o dispositivo simulado quando a configuração da rede for alterada.

Se você for afetado por esse problema, registre radares duplicados adicionais em http://bugreport.apple.com para obter prioridade aumentada.

Se você vir esse problema sem ter alterado as configurações de rede, esse não é um bug conhecido e você definitivamente deve arquivar um radar, indicando que o problema não é o bug alterado na configuração de rede.


7
Também tenho esse problema em um dispositivo.
Darren

@ Darren Então não é o problema que eu estava me referindo. Eu sugiro que você arquive um radar.
Jeremy Huddleston Sequoia

4
inclua o seu ID radar assim que faz a apresentação de duplicatas mais fácil
Daniel Galasko

11

o que resolveu o problema para mim foi reiniciar o simulador e redefinir o conteúdo e as configurações.


Também ajuda a matar o aplicativo antes da reinicialização do simulador e reiniciar o Mac. Costumo mudar de lugar com diferentes pontos wifi e este é um procedimento que corrige o problema para mim.
Vladimír Slavík

11

Também tem um problema com o beta 5 e o AFNetworking 1.3 ao executar no simulador do iOS 8 que resulta em um erro de conexão:

Domínio = NSURLErrorDomain Code = -1005 "A conexão de rede foi perdida."

O mesmo código funciona bem nos simuladores do iOS 7 e 7.1 e meu proxy de depuração mostra que a falha ocorre antes que uma conexão seja realmente tentada (ou seja, nenhuma solicitação registrada).

Rastreei a falha do NSURLConnection e relatei um erro à Apple. Veja a linha 5 na imagem em anexo:

Delegado do cliente NSURLConnection falhou erro.

Alterar para usar httpspermite a conexão de simuladores do iOS 8, embora com erros intermitentes.

O problema ainda está presente no Xcode 6.01 (gm).


Eu vejo o mesmo problema com NSURLSession e NSURLConnection, isso exclui o problema com AFNetworking. Também achei que funciona com https e falhando com http. Ainda não consegui encontrar nenhuma solução, você conseguiu alguma solução?
VoidStack

Nenhuma resolução relatada como bug (18072300) adicionará um comentário sobre o funcionamento do https que é uma boa informação.
ptc

você pode colar o link do bug aqui? Graças porque eu acho que eu tenho o mesmo problema, mas eu só uso o NSURLConnection (e delegados), mas eu recebo a mesma mensagem de erro
szuniverse

Não é possível compartilhar o relatório de bug da Apple. Ainda aberto e presente no XCODE 6 beta 7. Se você enviar um relatório de bug também, isso ajudará com prioridade.
ptc

Parece que esse problema está no simulador do iOS e eu estava cansado do dispositivo real, ele funciona bem. Depuração adicional que encontrei problema é sobre a porta no simulador iOS, a porta https 443 funciona bem e eu estava usando o 8080 para http que costumava falhar. Tentei usar outras portas e consegui fazer chamadas http no simulador do iOS. Looks como bug no beta Xcode 6, necessidade de esperar por Xcode estável 6.
VoidStack

10

Eu estava com esse problema ao usar o Alamofire. Meu erro foi enviar um dicionário vazio [:]para os parâmetros em uma GETsolicitação, em vez de enviar nilparâmetros.

Espero que isto ajude!


GET e POST com o dicionário de corpo vazio [:] causarão esse erro aleatoriamente. Estou usando o Python Flask para as APIs REST de back-end, isso também pode ser útil.
Mahmoud Fayez

10

A abertura de Charles resolveu o problema para mim, o que parece muito estranho ...

Charles é um proxy HTTP / monitor HTTP / Proxy Reverso que permite que um desenvolvedor visualize todo o tráfego HTTP e SSL / HTTPS entre sua máquina e a Internet. Isso inclui solicitações, respostas e cabeçalhos HTTP (que contêm os cookies e as informações de cache).


1
Isso funciona para mim também, eu acho, porque charles utiliza um certificado SSL para o proxy os pedidos sumulator ele faz um truque semelhante a usar https
thisispete

1
Isso funciona para mim sempre! Já tentei 30 vezes e funciona 30 em 30. Eu pensei que era por acaso, mas é bom saber que não sou eu.
jdog

2
Charles é uma ferramenta de proxy que permite assistir o tráfego da sua máquina. Verifique charlesproxy.com para obter detalhes. O certificado Charles SSL pode interferir na capacidade do simulador de fazer solicitações de rede.
Colin Tremblay

@ColinTremblay Acho que seu simulador / dispositivo está configurado para usar proxy. A remoção do proxy também funcionará.
bikram990

Ridiculamente, isso funcionou para mim também. Precisava abrir Charles e redefinir as configurações do iOS Simulator.
Matt Andrews

6

Veja o comentário de pjebs em 5 de janeiro no 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;
}

Além disso, algumas sugestões para se reconectar ao site,

ou seja, disparando a solicitação POST DUAS VEZES

Solução: use um método para fazer a conexão com o site, return (id), se a conexão de rede foi perdida, volte a usar o mesmo 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;
     }

}

Método 1 é me ajudou muito .. Obrigado
Abhishek Mitra

4

Eu estava recebendo esse erro também, mas em dispositivos reais, e não no simulador. Percebemos o erro ao acessar nosso back-end heroku em HTTPS (servidor gunicorn) e fazer POSTS com grandes empresas (qualquer coisa acima de 64 KB). Usamos HTTP Basic Auth para autenticação e percebemos que o erro foi resolvido NÃO usando o didReceiveChallenge:método delegate em NSURLSession, mas inserindo a autenticação no cabeçalho da solicitação original por meio da adição Authentiation: Basic <Base64Encoded UserName:Password>. Isso evita que o 401 necessário acione a didReceiveChallenge:mensagem delegada e a conexão de rede subseqüente seja perdida.


Muito obrigado pelo seu valioso comentário. Você está certo se eu fizer o upload abaixo da string base64 da imagem de 64 kb, ela será carregada com êxito.
Vinayak Bhor

3

Eu tive o mesmo problema. Solução era simples, eu configurei HTTPBody, mas não definiu HTTPMethoda POST. Depois de consertar isso, estava tudo bem.


3

Eu tive o mesmo problema. Não sei como o AFNetworking implementa a solicitação https, mas o motivo é o problema de cache do NSURLSession.

Depois que meu aplicativo voltar do safari e postar uma solicitação http, o erro "falha no carregamento http 1005" será exibido. Se eu parar de usar "[NSURLSession sharedSession]", mas usar uma instância configurável NSURLSession para chamar o método "dataTaskWithRequest:" da seguinte maneira, o problema será resolvido.

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

Lembre-se de definir config.URLCache = nil;.


1
Eu acho que todos aqueles que reiniciam o dispositivo / simulador ou redefinem os dados devem analisar essa resposta. Para mim, todas as ações deles parecem limpar o cache, o que realmente corrige o problema. Portanto, provavelmente é um problema de cache de URL. Vou testá-lo agora.
Kamran Khan

2

Eu tive que sair do XCode, excluir o conteúdo da pasta DerivedData (~ / Library / Developer / Xcode / DerivedData ou / Library / Developer / Xcode / DerivedData) e sair do simulador para fazer esse trabalho.


1
A única ação relevante nessa lista foi reiniciar o simulador. Reiniciar o Xcode e excluir dados derivados é excessivo.
Jeremy Huddleston Sequoia

2

Também tenho esse problema, executando em um dispositivo iOS 8. É detalhado um pouco mais aqui e parece ser um caso de iOS tentando usar conexões que já atingiram o tempo limite. Meu problema não é o mesmo que o problema do Keep-Alive, explicado nesse link, mas parece ser o mesmo resultado final.

Eu corrigi meu problema executando um bloco recursivo sempre que recebo um erro -1005 e isso faz com que a conexão acabe, mesmo que às vezes a recursão possa ser repetida por mais de 100 vezes antes da conexão funcionar, no entanto, apenas adiciona apenas um segundo à execução vezes e aposto que é exatamente o tempo que o depurador leva para imprimir o NSLog's para mim.

Eis como executo um bloco recursivo com o AFNetworking: Adicione este código ao seu arquivo de classe de conexão

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

Em seguida, use-o assim:

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

Você verá que eu uso uma AFHTTPRequestOperationsubclasse, mas adicione seu próprio código de solicitação. A parte importante é ligar recurse(@offset.intValue+1));para que o bloco seja chamado novamente.


O que é a classe MyAFHTTPRequestOperation?
jdog

É apenas uma subclasse AFHTTPRequestOperation. Eu o uso para predefinir algumas coisas, como tempo limite e autenticação.
Darren

2

Se o problema estiver ocorrendo em um dispositivo, verifique se o tráfego está passando por um proxy (Configurações> Wi-Fi> (informações)> Proxy HTTP). Eu tinha o meu dispositivo configurado para usar com Charles, mas esqueci o proxy. Parece que sem Charles realmente executando esse erro ocorre.


2

Se alguém receber esse erro ao fazer upload de arquivos para um servidor back-end, verifique se o servidor de recebimento possui um tamanho máximo de conteúdo permitido para sua mídia. No meu caso, o NGINX exigiu um valor mais alto client_max_body_size. O NGINX rejeitaria a solicitação antes que o upload fosse feito, para que nenhum código de erro voltasse.


2

Eu estava recebendo o erro em um dispositivo iOS 7 quando estava usando o Xcode 6.2 beta.

Voltar ao Xcode 6.2 beta para 6.1.1 corrigiu o problema, pelo menos em um dispositivo iOS 7.


Acho que não há nada a resolver: o SO subjacente descarta a conexão por um motivo legítimo ou não. Um aplicativo deve estar preparado para lidar com ele (trabalhar offline ou o que for). Supondo que o SDK em sua versão específica do xcode não seja um buggy, é claro: como minha resposta sugere, o 6.2 provavelmente foi o buggy, enquanto o 6.1.1 foi bom. Algo semelhante pode ser observado agora quando o xcode 6.4 parece razoavelmente estável, enquanto 7.0.1 é um software de nível alfa. Ou assim parece.
Anton Tropashko

2

Na 2017-01-25Apple, lançou uma sessão de perguntas e respostas técnicas sobre esse erro:

Perguntas e respostas técnicas da Apple QA1941

Manipulação de erros "A conexão de rede foi perdida"

R: NSURLErrorNetworkConnectionLost é o erro -1005 no domínio de erro NSURLErrorDomain e é exibido aos usuários como "A conexão de rede foi perdida". Esse erro significa que a conexão TCP subjacente que está carregando a solicitação HTTP foi desconectada enquanto a solicitação HTTP estava em andamento (veja abaixo para obter mais informações sobre isso). Em algumas circunstâncias, o NSURLSession pode repetir essas solicitações automaticamente (especificamente, se a solicitação for idempotente), mas em outras circunstâncias isso não é permitido pelos padrões HTTP.

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


1

Entendi o problema por meses e finalmente descobri que quando desabilitamos o DNSSEC em nosso domínio da API, tudo estava ok: simple_smile:


2
Você poderia por favor elaborar?
Groot

1

Eu estava me conectando através de uma VPN. Desativar a VPN resolveu o problema.


1

Eu estava atingindo esse erro ao passar um NSURLRequest para uma NSURLSession sem definir o HTTPMethod da solicitação .

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

Domínio de erro = NSURLErrorDomain Code = -1005 "A conexão de rede foi perdida."

Adicione o HTTPMethod, porém, e a conexão funcionará bem

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

1

Teste se você pode solicitar outros aplicativos (como o safari). Caso contrário, pode ser algo no seu computador. No meu caso, tive esse problema com o Avast Antivirus, que estava bloqueando minha solicitação de simuladores (não me pergunte o porquê).


1

A reinicialização do computador corrigiu o problema para mim com o Xcode9.1. Eu havia reiniciado o simulador e o Xcode, ele não funciona.


1

Eu estava enfrentando o mesmo problema, ativei o Network Link Conditioner para testes de rede lentos para o aplicativo. Isso estava criando esse erro algumas vezes. Quando eu o desabilitei Settings > Developer > Network Link Conditioner, ele resolveu o meu problema.

insira a descrição da imagem aqui

Espero que isso ajude alguém.


1

Além de todas as respostas, encontrei uma ótima solução. Na verdade, o problema relacionado à falha na conexão de rede para o iOS 12 onword ocorre porque há um erro no iOS 12.0 onword. E ainda a resolver. Eu havia passado pela comunidade do git hub por um problema relacionado ao AFNetworking quando o aplicativo veio de segundo plano e tenta fazer chamadas de rede e falha ao estabelecer a conexão. Eu passo 3 dias nisso e tenta muitas coisas para chegar à causa raiz disso e não encontrei nada. Finalmente, recebi alguma luz no escuro quando red neste blog https://github.com/AFNetworking/AFNetworking/issues/4279

Está dizendo que há um bug no iOS 12. Basicamente, você não pode esperar que uma chamada de rede seja concluída se o aplicativo não estiver em primeiro plano. E devido a esse bug, as chamadas de rede são descartadas e a rede falha nos logs.

Minha melhor sugestão para você é fornecer algum atraso quando o aplicativo estiver passando de segundo plano para primeiro plano e houver uma chamada de rede. Faça essa chamada de rede no envio assíncrona com algum atraso. Você nunca terá queda de chamadas de rede ou perda de conexão.

Não espere que a Apple deixe esse problema resolver para o iOS 12, pois ainda está para corrigir. Você pode seguir essa solução alternativa, fornecendo algum atraso para sua solicitação de rede, seja NSURLConnection, NSURLSession ou AFNetworking ou ALAMOFIRE. Felicidades :)


1

No meu caso, foi porque eu estava me conectando ao HTTP e estava sendo executado em HTTPS


0

Eu estava tendo esse problema pelo seguinte motivo.

TLDR: verifique se você está enviando uma GETsolicitação que deve estar enviando os parâmetros no URL em vez de na NSURLRequest's HTTBodypropriedade.

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

Eu montei uma abstração de rede no meu aplicativo e estava funcionando muito bem para todos os meus pedidos.

Adicionei uma nova solicitação a outro serviço da web (não o meu) e ele começou a me exibir esse erro.

Fui a um playground e comecei do zero criando um pedido de barebones, e funcionou. Então comecei a me aproximar da minha abstração até encontrar a causa.

Minha implementação de abstração teve um erro: eu estava enviando uma solicitação que deveria enviar parâmetros codificados no URL e também preenchendo a NSURLRequest's HTTBodypropriedade com os parâmetros de consulta. Assim que eu removi o HTTPBodyque funcionou.


0

Eu estava recebendo esse erro e também percebe que o aplicativo Postman também estava caindo, mas estava trabalhando no aplicativo Advanced Rest Client (ARC) e no Android. Então, eu tive que instalar o Charles para depurar a comunicação e notei que o código de resposta era -1. O problema era que o programador REST esqueceu de retornar o código de resposta 200.

Espero que isso ajude outros desenvolvedores.


0

Sempre que ocorreu o erro -1005, é necessário chamar a API novamente.

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

Você precisa adicionar seu código para chamar a função novamente. Certifique-se de que você foi chamado de método uma vez caso contrário, seu loop recursivo de chamada.


0

Eu enfrentei o mesmo problema ao ligar usando o servidor da minha empresa a partir do aplicativo iOS 12 com um dispositivo físico. O problema era que o disco rígido do servidor estava cheio. Liberar espaço no servidor resolveu o problema.

Encontrei o mesmo erro em outra situação, devido a um tempo limite não parametrizável por meio da API de rede padrão fornecida pela Apple ( URLSession.timeoutIntervalForRequeste URLSession.timeoutIntervalForResource). Mesmo lá .. resposta do servidor feito mais rápido resolveu o problema

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.