Error Domain=NSURLErrorDomain Code=-1005 “The network connection was lost.”

匿名 (未验证) 提交于 2019-12-03 02:09:01

问题:

I have an application which works fine on Xcode6-Beta1 and Xcode6-Beta2 with both iOS7 and iOS8. But with Xcode6-Beta3, Beta4, Beta5 I'm facing network issues with iOS8 but everything works fine on iOS7. I get the error "The network connection was lost.". The error is as follows:

Error: Error Domain=NSURLErrorDomain Code=-1005 "The network connection was lost." UserInfo=0x7ba8e5b0 {NSErrorFailingURLStringKey=, _kCFStreamErrorCodeKey=57, NSErrorFailingURLKey=, NSLocalizedDescription=The network connection was lost., _kCFStreamErrorDomainKey=1, NSUnderlyingError=0x7a6957e0 "The network connection was lost."}

I use AFNetworking 2.x and the following code snippet to make the network call:

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

I tried NSURLSession but still receive the same error.

回答1:

Restarting the simulator fixed the issue for me.



回答2:

We had this exact error and it turned out to be an issue with the underlying HTTP implementation of NSURLRequest:

As far as we can tell, when iOS 8/9/10/11 receive an HTTP response with a Keep-Alive header, it keeps this connection to re-use later (as it should), but it keeps it for more than the timeout parameter of the Keep-Alive header (it seems to always keep the connection alive for 30 seconds.) Then when a second request is sent by the app less than 30 seconds later, it tries to re-use a connection that might have been dropped by the server (if more than the real Keep-Alive has elapsed).

Here are the solutions we have found so far:

  • Increase the timeout parameter of the server above 30 seconds. It looks like iOS is always behaving as if the server will keep the connection open for 30 seconds regardless of the value provided in the Keep-Alive header. (This can be done for Apache by setting the KeepAliveTimeout option.
  • You can simply disable the keep alive mechanism for iOS clients based on the User-Agent of your app (e.g. for Apache: BrowserMatch "iOS 8\." nokeepalive in the mod file setenvif.conf)
  • If you don't have access to the server, you can try sending your requests with a Connection: close header: this will tell the server to drop the connection immediately and to respond without any keep alive headers. BUT at the moment, NSURLSession seems to override the Connection header when the requests are sent (we didn't test this solution extensively as we can tweak the Apache configuration)


回答3:

For mine, Resetting content and settings of Simulator works. To reset the simulator follow the steps:

iOS Simulator -> Reset Content and Settings -> Press Reset (on the warning which will come)



回答4:

The iOS 8.0 simulator runtime has a bug whereby if your network configuration changes while the simulated device is booted, higher level APIs (eg: CFNetwork) in the simulated runtime will think that it has lost network connectivity. Currently, the advised workaround is to simply reboot the simulated device when your network configuration changes.

If you are impacted by this issue, please file additional duplicate radars at http://bugreport.apple.com to get it increased priority.

If you see this issue without having changed network configurations, then that is not a known bug, and you should definitely file a radar, indicating that the issue is not the known network-configuration-changed bug.



回答5:

Also have a problem with beta 5 and AFNetworking 1.3 when running on iOS8 simulator that results in a connection error "Domain=NSURLErrorDomain Code=-1005 "The network connection was lost."". The same code works fine on iOS7 and 7.1 simulators and my debugging proxy shows that the failure occurs before a connection is actually attempted (i.e. no requests logged). I have tracked the failure to NSURLConnection and reported bug to Apple. See attached line 5 in attached image.

. Changing to use https allows connection from iOS8 simulators albeit with intermittent errors. Problem is still present in Xcode 6.01 (gm).


回答6:

what solved the problem for me was to restart simulator ,and reset content and settings.



回答7:

Opening Charles resolved the issue for me, which seems very strange...



回答8:

See pjebs comment on Jan 5 on Github.

Method1 :

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

Also some suggests to re-connect to the site,

i.e. Firing the POST request TWICE

Solution: Use a method to do connection to the site, return (id), if the network connection was lost, return to use the same method.

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


回答9:

I was experiencing this problem while using Alamofire. My mistake was that I was sending an empty dictionary [:] for the parameters on a GET request, rather than sending nil parameters.

Hope this helps!



回答10:

I have this issue also, running on an iOS 8 device. It is detailed some more here and seems to be a case of iOS trying to use connections that have already timed out. My issue isn't the same as the Keep-Alive problem explained in that link, however it seems to be the same end result.

I have corrected my problem by running a recursive block whenever I receive an error -1005 and this makes the connection eventually get through even though sometimes the recursion can loop for 100+ times before the connection works, however it only adds a mere second onto run times and I bet that is just the time it takes the debugger to print the NSLog's for me.

Here's how I run a recursive block with AFNetworking: Add this code to your connection class file

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

Then use it likes this:

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

You'll see that I use a AFHTTPRequestOperation subclass but add your own request code. The important part is calling recurse(@offset.intValue+1)); to make the block be called again.



回答11:

If anyone is getting this error while uploading files to a backend server, make sure the receiving server has a maximum content size that is allowable for your media. In my case, NGINX required a higher client_max_body_size. NGINX would reject the request before the uploading was done so no error code came back.



回答12:

I was getting this error as well, but on actual devices rather than the simulator. We noticed the error when accessing our heroku backend on HTTPS (gunicorn server), and doing POSTS with large bodys (anything over 64Kb). We use HTTP Basic Auth for authentication, and noticed the error was resolved by NOT using the didReceiveChallenge: delegate method on NSURLSession, but rather baking in the Authentication into the original request header via adding Authentiation: Basic <Base64Encoded UserName:Password>. This prevents the necessary 401 to trigger the didReceiveChallenge: delegate message, and the subsequent network connection lost.



回答13:

I had same problem. Solution was simple, I've set HTTPBody, but haven't set HTTPMethod to POST. After fixing this, everything was fine.



回答14:

I had to exit XCode, delete DerivedData folder contents (~/Library/Developer/Xcode/DerivedData or /Library/Developer/Xcode/DerivedData) and exit simulator to make this work.



回答15:

I was getting the error even on ios7 device when I was using xcode 6.2 beta. switching back from xcode 6.2 beta to 6.1.1 fixed the issue. at least on ios7 device.



回答16:

If the problem is occurring on a device, check if traffic is going through a proxy (Settings > Wi-Fi > (info) > HTTP Proxy). I had my device setup to use with Charles, but forgot about the proxy. Seems that without Charles actually running this error occurs.



回答17:

I was connecting via a VPN. Disabling the VPN solved the problem.



回答18:

I was hitting this error when passing an NSURLRequest to an NSURLSession without setting the request's HTTPMethod.

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

Error Domain=NSURLErrorDomain Code=-1005 "The network connection was lost."

Add the HTTPMethod, though, and the connection works fine

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


回答19:

Test if you can request from other apps (like safari). If not might be something on your computer. In my case I had this problem with Avast Antivirus, which was blocking my simulators request (don't ask me why).



回答20:

Restarting the computer fixed the issue for me with Xcode9.1. I had restarted the simulator and Xcode, it doesn't work.



回答21:

Got the issue for months, and finally discovered that when we disable DNSSEC on our api domain, everything was ok :simple_smile:



回答22:

I was having this issue for the following reason.

TLDR: Check if you are sending a GET request that should be sending the parameters on the url instead of on the NSURLRequest's HTTBody property.

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

I had mounted a network abstraction on my app, and it was working pretty well for all my requests.

I added a new request to another web service (not my own) and it started throwing me this error.

I went to a playground and started from the ground up building a barebones request, and it worked. So I started moving closer to my abstraction until I found the cause.

My abstraction implementation had a bug: I was sending a request that was supposed to send parameters encoded in the url and I was also filling the NSURLRequest's HTTBody property with the query parameters as well. As soon as I removed the HTTPBody it worked.



回答23:

I was receiving this error and also notices that the application Postman was also falling but was working in app Advanced Rest Client (ARC) and working in Android. So i had to install Charles to debug the communication and I notices that response code was -1. The problem was that REST programmer forgot to return response code 200.

I hope that this help other developers.



回答24:

Whenever got error -1005 then need to call API Again.

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

You need to Add your code to call function again. MakeSure that you were call method once otherwise its call recursive loop.



标签
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!