Introduction

In AFNetworking, timeouts are configured through the underlying NSURLSessionConfiguration or through the request serializer on the manager. The right choice depends on whether you want a default timeout for all requests or a one-off timeout for a specific request.

Set a Default Timeout with Session Configuration

If you want all requests created by an AFHTTPSessionManager to share the same timeout policy, configure the session before creating the manager.

1#import <AFNetworking/AFNetworking.h>
2
3NSURLSessionConfiguration *configuration = [NSURLSessionConfiguration defaultSessionConfiguration];
4configuration.timeoutIntervalForRequest = 30.0;
5configuration.timeoutIntervalForResource = 60.0;
6
7AFHTTPSessionManager *manager =
8    [[AFHTTPSessionManager alloc] initWithBaseURL:nil sessionConfiguration:configuration];

These two values are related but different:

• 'timeoutIntervalForRequest is the timeout for an individual request attempt'
• 'timeoutIntervalForResource is the maximum total time allowed for loading the resource'

For most app code, setting both intentionally is clearer than relying on platform defaults.

Set Timeout Through the Request Serializer

AFNetworking also lets you set the request timeout through the request serializer.

AFHTTPSessionManager *manager = [AFHTTPSessionManager manager];
manager.requestSerializer.timeoutInterval = 30.0;

This is a common and convenient approach when you already use a shared manager instance and want to change the default request timeout without rebuilding the session configuration manually.

In many ordinary AFNetworking codebases, this is the most direct answer.

Full Request Example

1AFHTTPSessionManager *manager = [AFHTTPSessionManager manager];
2manager.requestSerializer.timeoutInterval = 20.0;
3
4[manager GET:@"https://httpbin.org/delay/1"
5  parameters:nil
6    headers:nil
7     progress:nil
8      success:^(NSURLSessionDataTask *task, id responseObject) {
9          NSLog(@"Success: %@", responseObject);
10      }
11      failure:^(NSURLSessionDataTask *task, NSError *error) {
12          NSLog(@"Failure: %@", error);
13      }];

If the server responds before 20 seconds, the request succeeds normally. If not, the failure block receives the timeout error.

Per-Request Timeout

If only one request needs a different timeout, create an NSURLRequest and set its timeout interval explicitly.

1NSMutableURLRequest *request =
2    [[AFHTTPRequestSerializer serializer] requestWithMethod:@"GET"
3                                                  URLString:@"https://httpbin.org/delay/5"
4                                                 parameters:nil
5                                                      error:nil];
6
7request.timeoutInterval = 2.0;
8
9AFHTTPSessionManager *manager = [AFHTTPSessionManager manager];
10
11NSURLSessionDataTask *task =
12    [manager dataTaskWithRequest:request
13                  uploadProgress:nil
14                downloadProgress:nil
15               completionHandler:^(NSURLResponse *response, id responseObject, NSError *error) {
16                   if (error) {
17                       NSLog(@"Request failed: %@", error);
18                   } else {
19                       NSLog(@"Response: %@", responseObject);
20                   }
21               }];
22
23[task resume];

That avoids changing the shared timeout policy for unrelated requests.

Timeout Policy Is an Application Decision

Do not set timeouts arbitrarily. A sensible value depends on the endpoint:

• short timeouts for interactive UI actions
• longer timeouts for large uploads or reports
• separate retry policy if retries are allowed

A single global timeout for everything is convenient, but it is not always the right operational design.

Be Careful with Shared Managers

If your app uses one long-lived AFHTTPSessionManager, changing requestSerializer.timeoutInterval affects future requests created through that manager. That can accidentally change behavior in unrelated code paths.

For that reason, teams often use either:

• one manager per API domain with stable defaults
• a shared manager plus explicit per-request overrides for exceptions

That is safer than mutating a global manager ad hoc from many places in the app.

Recognize Timeout Errors

When a request times out, the error is usually surfaced as an NSURLErrorTimedOut case inside the failure callback.

if (error.code == NSURLErrorTimedOut) {
    NSLog(@"The request timed out");
}

That lets you distinguish timeouts from DNS failures, certificate problems, and ordinary HTTP error responses.

Common Pitfalls

• Setting the timeout on the wrong object and assuming it affects existing requests.
• Using one shared manager and changing its timeout globally for a one-off call.
• Confusing request timeout with total resource timeout.
• Treating every timeout as a reason to retry automatically.
• Debugging server latency without first checking the client timeout configuration.

Summary

• In AFNetworking, timeouts are usually set through NSURLSessionConfiguration or requestSerializer.timeoutInterval.
• Use session configuration for stable defaults across a manager.
• Use a custom NSURLRequest when one request needs a special timeout.
• Choose timeout values based on endpoint behavior, not convenience alone.
• Handle timeout errors explicitly so they are not confused with other network failures.