Lỗi tên miền = NSURLErrorDomain Code = -1005 Triệu Kết nối mạng bị mất.

Tôi có một ứng dụng hoạt động tốt trên Xcode6-Beta1 và Xcode6-Beta2 với cả iOS7 và iOS8. Nhưng với Xcode6-Beta3, Beta4, Beta5 tôi đang gặp vấn đề về mạng với iOS8 nhưng mọi thứ đều hoạt động tốt trên iOS7. Tôi nhận được lỗi "The network connection was lost.". Lỗi như sau:

Lỗi: Lỗi tên miền = NSURLErrorDomain Code = -1005 "Kết nối mạng bị mất." UserInfo = 0x7ba8e5b0 {NSErrorFailingURLStringKey =, _kCFStreamErrorCodeKey = 57, NSErrorFailingURLKey =, NSLrrFF

Tôi sử dụng AFNetworking 2.x và đoạn mã sau để thực hiện cuộc gọi mạng:

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

Tôi đã thử NSURLSessionnhưng vẫn nhận được lỗi tương tự.

Khởi động lại trình giả lập đã khắc phục sự cố cho tôi.

Chúng tôi đã có lỗi chính xác này và hóa ra đó là một vấn đề với việc triển khai HTTP cơ bản của NSURLRequest:

Theo như chúng tôi có thể nói, khi iOS 8/9/10/11 nhận được phản hồi HTTP với Keep-Alivetiêu đề, nó sẽ giữ kết nối này để sử dụng lại sau (nếu cần), nhưng nó giữ cho nó nhiều hơn timeouttham số của Tiêu đề Keep-Alive (dường như luôn giữ kết nối tồn tại trong 30 giây.) Sau đó, khi ứng dụng thứ hai được gửi bởi ứng dụng chưa đầy 30 giây sau, nó sẽ cố gắng sử dụng lại kết nối có thể bị máy chủ đánh rơi (nếu nhiều hơn thực tế Keep-Aliveđã trôi qua).

Dưới đây là các giải pháp chúng tôi đã tìm thấy cho đến nay:

• Tăng tham số thời gian chờ của máy chủ trên 30 giây. Có vẻ như iOS luôn hoạt động như thể máy chủ sẽ giữ kết nối mở trong 30 giây bất kể giá trị được cung cấp trong tiêu đề Keep-Alive. (Điều này có thể được thực hiện cho Apache bằng cách đặt KeepAliveTimeouttùy chọn.
• Bạn chỉ có thể vô hiệu hóa cơ chế giữ mạng cho máy khách iOS dựa trên Tác nhân người dùng của ứng dụng của bạn (ví dụ: đối với Apache: BrowserMatch "iOS 8\." nokeepalivetrong tệp mod setenvif.conf)
• Nếu bạn không có quyền truy cập vào máy chủ, bạn có thể thử gửi yêu cầu của mình bằng một Connection: closetiêu đề: điều này sẽ yêu cầu máy chủ hủy kết nối ngay lập tức và trả lời mà không có bất kỳ tiêu đề nào còn tồn tại. NHƯNG tại thời điểm này, NSURLSession dường như ghi đè Connectiontiêu đề khi các yêu cầu được gửi (chúng tôi đã không kiểm tra rộng rãi giải pháp này vì chúng tôi có thể điều chỉnh cấu hình Apache)

Đối với tôi, Resetting content and settingscủa Simulator hoạt động. Để đặt lại trình giả lập, hãy làm theo các bước:

Trình mô phỏng iOS -> Đặt lại Nội dung và Cài đặt -> Nhấn Đặt lại (trên cảnh báo sẽ đến)

Thời gian chạy giả lập iOS 8.0 có lỗi, nếu cấu hình mạng của bạn thay đổi trong khi thiết bị mô phỏng được khởi động, các API cấp cao hơn (ví dụ: CFNetwork) trong thời gian chạy mô phỏng sẽ nghĩ rằng nó đã mất kết nối mạng. Hiện tại, cách giải quyết được khuyên là chỉ cần khởi động lại thiết bị mô phỏng khi cấu hình mạng của bạn thay đổi.

Nếu bạn bị ảnh hưởng bởi vấn đề này, vui lòng gửi thêm các radar trùng lặp tại http://ormsreport.apple.com để được tăng mức độ ưu tiên.

Nếu bạn thấy vấn đề này mà không thay đổi cấu hình mạng, thì đó không phải là lỗi đã biết và bạn chắc chắn nên gửi một radar, chỉ ra rằng vấn đề không phải là lỗi đã thay đổi cấu hình mạng đã biết.

Điều giải quyết vấn đề cho tôi là khởi động lại trình giả lập, và đặt lại nội dung và cài đặt.

Cũng gặp sự cố với beta 5 và AFNetworking 1.3 khi chạy trên trình giả lập iOS 8 dẫn đến lỗi kết nối:

Tên miền = NSURLErrorDomain Code = -1005 "Kết nối mạng bị mất."

Mã tương tự hoạt động tốt trên trình giả lập iOS 7 và 7.1 và proxy gỡ lỗi của tôi cho thấy lỗi xảy ra trước khi kết nối thực sự được thử (nghĩa là không có yêu cầu nào được ghi lại).

Tôi đã theo dõi sự thất bại của NSURLConnection và báo cáo lỗi cho Apple. Xem dòng 5 trong hình ảnh đính kèm:

.

Thay đổi để sử dụng httpscho phép kết nối từ trình giả lập iOS 8 mặc dù có lỗi không liên tục.

Vấn đề vẫn còn trong Xcode 6.01 (gm).

Tôi đã gặp vấn đề này trong khi sử dụng Alamofire. Sai lầm của tôi là tôi đã gửi một từ điển trống [:]cho các tham số theo GETyêu cầu, thay vì gửi niltham số.

Hi vọng điêu nay co ich!

Khai mạc Charles đã giải quyết vấn đề cho tôi, điều này có vẻ rất lạ ...

Charles là proxy HTTP / màn hình HTTP / Proxy ngược cho phép nhà phát triển xem tất cả lưu lượng HTTP và SSL / HTTPS giữa máy của họ và Internet. Điều này bao gồm các yêu cầu, phản hồi và các tiêu đề HTTP (chứa cookie và thông tin bộ đệm).

Xem bình luận pjebs vào ngày 5 tháng 1 trên Github.

Phương pháp 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;
}

Ngoài ra một số gợi ý để kết nối lại với trang web,

tức là bắn yêu cầu POST TWICE

Giải pháp: Sử dụng một phương thức để thực hiện kết nối đến trang web, return (id), nếu kết nối mạng bị mất, quay lại sử dụng cùng một phương thức.

Phương pháp 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;
     }

}

Tôi cũng đã nhận được lỗi này, nhưng trên các thiết bị thực tế chứ không phải là trình giả lập. Chúng tôi đã nhận thấy lỗi khi truy cập vào phụ trợ heroku của chúng tôi trên HTTPS (máy chủ gunicorn) và thực hiện POSTS với số lượng lớn (mọi thứ trên 64Kb). Chúng tôi sử dụng HTTP Basic Auth để xác thực và nhận thấy lỗi đã được khắc phục bằng cách KHÔNG sử dụng didReceiveChallenge:phương thức ủy nhiệm trên NSURLSession, mà thay vào đó là nướng trong Xác thực vào tiêu đề yêu cầu ban đầu thông qua việc thêm Authentiation: Basic <Base64Encoded UserName:Password>. Điều này ngăn chặn 401 cần thiết để kích hoạt didReceiveChallenge:thông báo đại biểu và mất kết nối mạng tiếp theo.

Tôi đã có vấn đề tương tự. Giải pháp là đơn giản, tôi đã thiết lập HTTPBody, nhưng đã không được thiết lập HTTPMethodđể POST. Sau khi sửa lỗi này, mọi thứ đều ổn.

Tôi đã từng gặp vấn đề tương tự. Tôi không biết làm thế nào AFNetworking thực hiện yêu cầu https, nhưng lý do đối với tôi là vấn đề bộ nhớ cache của NSURLSession.

Sau khi ứng dụng của tôi theo dõi trở lại từ safari và sau đó gửi yêu cầu http, lỗi "tải http không thành công 1005" sẽ xuất hiện. Nếu tôi ngừng sử dụng "[NSURLSession sharedSession]", nhưng để sử dụng một cá thể NSURLSession có thể định cấu hình để gọi phương thức "dataTaskWithRequest:" như sau, vấn đề đã được giải quyết.

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

Chỉ cần nhớ để thiết lập config.URLCache = nil;.

Tôi đã phải thoát XCode, xóa nội dung thư mục DeruredData (~ / Library / Developer / Xcode / DeruredData hoặc / Library / Developer / Xcode / DeruredData) và thoát trình giả lập để thực hiện công việc này.

Tôi cũng gặp vấn đề này, chạy trên thiết bị iOS 8. Đây là chi tiết một số chi tiết ở đây và dường như là một trường hợp iOS đang cố gắng sử dụng các kết nối đã hết thời gian. Vấn đề của tôi không giống như vấn đề Keep-Alive được giải thích trong liên kết đó, tuy nhiên dường như đó là kết quả cuối cùng.

Tôi đã khắc phục sự cố của mình bằng cách chạy khối đệ quy bất cứ khi nào tôi gặp lỗi -1005 và điều này làm cho kết nối cuối cùng được khắc phục mặc dù đôi khi đệ quy có thể lặp lại hơn 100 lần trước khi kết nối hoạt động, tuy nhiên nó chỉ thêm một giây khi chạy lần và tôi cá rằng đó chỉ là thời gian mà trình gỡ lỗi cần để in NSLog cho tôi.

Đây là cách tôi chạy một khối đệ quy với AFNetworking: Thêm mã này vào tệp lớp kết nối của bạ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); };
}

Sau đó sử dụng nó như thế này:

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

Bạn sẽ thấy rằng tôi sử dụng một AFHTTPRequestOperationlớp con nhưng thêm mã yêu cầu của riêng bạn. Phần quan trọng là gọi recurse(@offset.intValue+1));để làm cho khối được gọi lại.

Nếu sự cố xảy ra trên thiết bị, hãy kiểm tra xem lưu lượng có đi qua proxy (Cài đặt> Wi-Fi> (thông tin)> Proxy HTTP). Tôi đã thiết lập thiết bị của mình để sử dụng với Charles, nhưng quên mất proxy. Có vẻ như không có Charles thực sự chạy lỗi này xảy ra.

Nếu bất kỳ ai cũng gặp phải lỗi này trong khi tải tệp lên máy chủ phụ trợ, hãy đảm bảo rằng máy chủ nhận có kích thước nội dung tối đa được phép cho phương tiện của bạn. Trong trường hợp của tôi, NGINX yêu cầu cao hơn client_max_body_size. NGINX sẽ từ chối yêu cầu trước khi tải lên xong để không có mã lỗi quay lại.

Tôi đã gặp lỗi trên thiết bị iOS 7 khi tôi đang sử dụng Xcode 6.2 beta.

Chuyển đổi lại từ Xcode 6.2 beta sang 6.1.1 đã khắc phục sự cố, ít nhất là trên thiết bị iOS 7.

Trên 2017-01-25Apple đã phát hành một câu hỏi kỹ thuật liên quan đến lỗi này:

Hỏi đáp kỹ thuật của Apple QA1941

Xử lý Kết nối mạng bị mất Lỗi lỗi

Trả lời: NSURLErrorNetworkConnectionLost bị lỗi -1005 trong miền lỗi NSURLErrorDomain và được hiển thị cho người dùng dưới dạng Bắt đầu Kết nối mạng bị mất. Lỗi này có nghĩa là kết nối TCP cơ bản mang yêu cầu HTTP bị ngắt kết nối trong khi yêu cầu HTTP đang được xử lý (xem bên dưới để biết thêm thông tin về điều này). Trong một số trường hợp, NSURLSession có thể thử lại các yêu cầu đó một cách tự động (cụ thể, nếu yêu cầu đó là tạm thời) nhưng trong các trường hợp khác, các tiêu chuẩn HTTP không cho phép.

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

Có vấn đề trong nhiều tháng và cuối cùng đã phát hiện ra rằng khi chúng tôi vô hiệu hóa DNSSEC trên miền api của mình, mọi thứ đều ổn: Simple_smile:

Tôi đã kết nối qua VPN. Vô hiệu hóa VPN đã giải quyết vấn đề.

Tôi đã gặp phải lỗi này khi chuyển NSURLRequest sang NSURLSession mà không đặt HTTPMethod của yêu cầu .

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

Lỗi tên miền = NSURLErrorDomain Code = -1005 "Kết nối mạng bị mất."

Thêm HTTPMethod, mặc dù, và kết nối hoạt động tốt

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

Kiểm tra nếu bạn có thể yêu cầu từ các ứng dụng khác (như safari). Nếu không có thể là một cái gì đó trên máy tính của bạn. Trong trường hợp của tôi, tôi gặp vấn đề này với Avast Antivirus, đã chặn yêu cầu giả lập của tôi (đừng hỏi tôi tại sao).

Khởi động lại máy tính đã khắc phục sự cố cho tôi với Xcode9.1. Tôi đã khởi động lại trình giả lập và Xcode, nó không hoạt động.

Tôi đã phải đối mặt với cùng một vấn đề, tôi đã kích hoạt Điều hòa liên kết mạng để kiểm tra mạng chậm cho ứng dụng. Điều đó đã tạo ra lỗi này một số lần, Khi tôi đã vô hiệu hóa nó Settings > Developer > Network Link Conditioner, nó đã giải quyết vấn đề của tôi.

Hy vọng điều này sẽ giúp ai đó.

Trong trường hợp của tôi, đó là vì tôi đã kết nối với HTTP và nó đang chạy trên HTTPS

Tôi đã có vấn đề này vì lý do sau.

TLDR: Kiểm tra xem bạn có đang gửi GETyêu cầu nên gửi các tham số trên url thay vì trên thuộc NSURLRequest's HTTBodytính không.

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

Tôi đã gắn một bản tóm tắt mạng trên ứng dụng của mình và nó hoạt động khá tốt cho tất cả các yêu cầu của tôi.

Tôi đã thêm một yêu cầu mới vào một dịch vụ web khác (không phải của riêng tôi) và nó bắt đầu ném cho tôi lỗi này.

Tôi đã đi đến một sân chơi và bắt đầu từ việc xây dựng một yêu cầu barebones, và nó đã hoạt động. Vì vậy, tôi bắt đầu tiến gần đến sự trừu tượng của mình cho đến khi tôi tìm ra nguyên nhân.

Việc triển khai trừu tượng hóa của tôi có một lỗi: Tôi đã gửi một yêu cầu được cho là gửi các tham số được mã hóa trong url và tôi cũng đang điền vào thuộc NSURLRequest's HTTBodytính với các tham số truy vấn. Ngay khi tôi gỡ bỏ HTTPBodynó hoạt động.

Tôi đã nhận được lỗi này và cũng nhận thấy rằng Postman cũng bị lỗi nhưng đang hoạt động trong ứng dụng Advanced Rest Client (ARC) và hoạt động trong Android. Vì vậy, tôi đã phải cài đặt Charles để gỡ lỗi liên lạc và tôi nhận thấy mã phản hồi là -1. Vấn đề là lập trình viên REST quên trả về mã phản hồi 200.

Tôi hy vọng rằng điều này sẽ giúp các nhà phát triển khác.

Bất cứ khi nào gặp lỗi -1005 thì cần gọi lại 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... 
       }
  }];

Bạn cần thêm mã của bạn để gọi lại chức năng. MakeSure rằng bạn đã gọi phương thức một lần nếu không vòng lặp đệ quy cuộc gọi của nó.

Trên tất cả các câu trả lời tôi tìm thấy một giải pháp tốt đẹp. Trên thực tế Vấn đề liên quan đến kết nối mạng không thành công cho onword iOS 12 là do có lỗi trong onword iOS 12.0. Và nó vẫn chưa được giải quyết. Tôi đã đi qua cộng đồng trung tâm git cho vấn đề liên quan đến AFNetworking khi ứng dụng xuất phát từ nền tảng và cố gắng thực hiện cuộc gọi mạng và không thành công khi thiết lập kết nối. Tôi dành 3 ngày cho việc này và cố gắng nhiều thứ để đi đến nguyên nhân gốc rễ cho việc này và không tìm thấy gì. Cuối cùng tôi cũng nhận được một chút ánh sáng trong bóng tối khi tôi viết blog này https://github.com/AFNetworking/AFNetworking/issues/4279

Người ta nói rằng có một lỗi trong iOS 12. Về cơ bản, bạn không thể mong đợi một cuộc gọi mạng sẽ hoàn tất nếu ứng dụng os không ở phía trước. Và do lỗi này, các cuộc gọi mạng bị hủy và chúng tôi gặp lỗi mạng trong nhật ký.

Đề nghị tốt nhất của tôi cho bạn là cung cấp một số độ trễ khi ứng dụng của bạn chuyển từ nền sang tiền cảnh và có cuộc gọi mạng. Thực hiện cuộc gọi mạng đó trong công văn không đồng bộ với một số độ trễ. Bạn sẽ không bao giờ bị rớt mạng hoặc mất kết nối mạng.

Đừng chờ đợi Apple để vấn đề này giải quyết cho iOS 12 vì nó vẫn chưa được khắc phục. Bạn có thể giải quyết vấn đề này bằng cách cung cấp một số độ trễ cho yêu cầu mạng của bạn là NSURLCconnectection, NSURLSession hoặc AFNetworking hoặc ALAMOFIRE. Chúc mừng :)

Tôi đã gặp vấn đề tương tự trong khi gọi bằng máy chủ của công ty tôi từ ứng dụng iOS 12 bằng thiết bị vật lý. Vấn đề là đĩa cứng máy chủ đã đầy. Giải phóng không gian trong máy chủ đã giải quyết vấn đề.

Tôi đã tìm thấy lỗi tương tự trong một tình huống khác mà tôi nghĩ do thời gian chờ không thể tham số thông qua API Mạng tiêu chuẩn do Apple cung cấp ( URLSession.timeoutIntervalForRequestvà URLSession.timeoutIntervalForResource). Ngay cả ở đó .. làm cho máy chủ trả lời nhanh hơn giải quyết vấn đề