Proxys in Swift verwenden: URLSession-Konfiguration für iOS und macOS

Wer Proxys in Swift verwenden möchte, stößt schnell auf eine Lücke in der offiziellen Dokumentation: URLSession bietet keine einfache proxy-Eigenschaft wie Python- oder Node.js-HTTP-Clients. Stattdessen müssen Entwickler auf URLSessionConfiguration.connectionProxyDictionary zurückgreifen, CFNetwork-Konstanten manuell setzen und sich um Proxy-Authentifizierung kümmern – ein Bereich, in dem Apple-Plattformen historisch inkonsistent sind. Dieser Guide zeigt, wie man Residential Proxys über gate.proxyhat.com:8080 in Swift-Projekte integriert, mit lauffähigem Code für iOS 15+ und macOS 12+.

Warum Proxys in Swift verwenden? Technischer Kontext

URLSession nutzt intern CFNetwork, das wiederum auf CFNetwork-Framework von Apple aufbaut. Proxy-Konfiguration erfolgt über ein Dictionary mit CFNetwork-spezifischen Schlüsseln, nicht über ein typisiertes Swift-Objekt. Das bedeutet: Sie arbeiten mit kCFNetworkProxiesHTTPEnable, kCFNetworkProxiesHTTPProxy und ähnlichen Konstanten aus CFNetwork/CFNetwork.h.

Die Herausforderungen dabei sind vielfältig:

• Authentifizierung: kCFProxyUsernameKey und kCFProxyPasswordKey werden von URLSession nicht zuverlässig an HTTP-Proxys gesendet. Sie müssen Proxy-Authorization-Header manuell setzen oder den urlSession(_:didReceive:completionHandler:)-Delegate-Callback implementieren.
• HTTPS-Proxying: Für TLS-Verbindungen benötigen Sie zusätzlich kCFNetworkProxiesHTTPSEnable und die HTTPS-Äquivalente.
• ATS-Beschränkungen: App Transport Security kann Proxy-Verbindungen blockieren, wenn der Proxy selbst nicht über TLS erreichbar ist.

Residential Proxys sind besonders wichtig, wenn App-Endpunkte Datacenter-IPs blockieren oder Inhalte regionenbeschränkt sind. Ein typisches Beispiel: Eine Preisvergleichs-App, die Daten von E-Commerce-Seiten in mehreren Ländern abruft, benötigt IP-Adressen aus echten Wohnnetzwerken, um CAPTCHAs und IP-Sperren zu vermeiden. Laut einer Imperva-Studie machten Bots im Jahr 2023 fast 50 % des gesamten Internet-Traffics aus, weshalb viele Webseiten aggressive Anti-Bot-Maßnahmen implementieren.

Grundlegende URLSession-Proxy-Konfiguration

Der erste Schritt ist die Konfiguration eines HTTP/HTTPS-Proxys über connectionProxyDictionary. Hier ist ein lauffähiges Beispiel, das sowohl HTTP als auch HTTPS über denselben Proxy leitet:

import Foundation

func makeProxySessionConfiguration(proxyHost: String, proxyPort: Int) -> URLSessionConfiguration {
    let config = URLSessionConfiguration.default
    
    // HTTP-Proxy aktivieren
    config.connectionProxyDictionary = [
        kCFNetworkProxiesHTTPEnable as String: true,
        kCFNetworkProxiesHTTPProxy as String: proxyHost,
        kCFNetworkProxiesHTTPPort as String: proxyPort,
        
        // HTTPS-Proxy aktivieren (CONNECT-Methode)
        kCFNetworkProxiesHTTPSEnable as String: true,
        kCFNetworkProxiesHTTPSProxy as String: proxyHost,
        kCFNetworkProxiesHTTPSPort as String: proxyPort
    ]
    
    // Zeitüberschreitungen für Produktion
    config.timeoutIntervalForRequest = 30
    config.timeoutIntervalForResource = 60
    
    return config
}

// ProxyHat-Gateway konfigurieren
let proxyConfig = makeProxySessionConfiguration(
    proxyHost: "gate.proxyhat.com",
    proxyPort: 8080
)

let session = URLSession(configuration: proxyConfig)

Diese Konfiguration leitet alle Anfragen über gate.proxyhat.com:8080. Beachten Sie, dass die Werte im Dictionary als String-Schlüssel und Any-Werte gespeichert werden – Swift erfordert hier explizites Casting.

Authentifizierung und Geo-Targeting

Problem: kCFProxyUsernameKey ist unzuverlässig

Apple-Dokumentation legt nahe, dass kCFProxyUsernameKey und kCFProxyPasswordKey im connectionProxyDictionary funktionieren. In der Praxis werden diese jedoch bei URLSession-Anfragen häufig ignoriert, insbesondere für HTTP-CONNECT-Tunnel bei HTTPS. Es gibt zwei zuverlässige Workarounds:

Lösung A: Manueller Proxy-Authorization-Header

import Foundation

func makeProxyAuthHeader(username: String, password: String) -> String {
    let credentials = "\(username):\(password)"
    let base64 = Data(credentials.utf8).base64EncodedString()
    return "Basic \(base64)"
}

// Geo-Targeting und Session in den Benutzernamen codieren
let proxyUser = "user-country-US-city-newyork-session-abc123"
let proxyPass = "deinPasswort"

let authHeader = makeProxyAuthHeader(
    username: proxyUser,
    password: proxyPass
)

var request = URLRequest(url: URL(string: "https://httpbin.org/ip")!)
request.setValue(authHeader, forHTTPHeaderField: "Proxy-Authorization")

let task = session.dataTask(with: request) { data, response, error in
    if let error = error {
        print("Fehler: \(error.localizedDescription)")
        return
    }
    if let data = data {
        print(String(data: data, encoding: .utf8) ?? "")
    }
}
task.resume()

Lösung B: URLSessionDelegate für 407-Challenge

Wenn der Proxy mit 407 Proxy Authentication Required antwortet, kann ein URLSessionDelegate die Credentials bereitstellen. Dies ist robuster, erfordert aber mehr Boilerplate:

import Foundation

final class ProxyAuthDelegate: NSObject, URLSessionDelegate {
    let proxyUsername: String
    let proxyPassword: String
    
    init(username: String, password: String) {
        self.proxyUsername = username
        self.proxyPassword = password
    }
    
    func urlSession(
        _ session: URLSession,
        didReceive challenge: URLAuthenticationChallenge,
        completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void
    ) {
        // Nur auf Proxy-Authentifizierung reagieren
        if challenge.protectionSpace.authenticationMethod == NSURLAuthenticationMethodHTTPProxy 
            || challenge.protectionSpace.authenticationMethod == NSURLAuthenticationMethodHTTPSProxy {
            
            let credential = URLCredential(
                user: proxyUsername,
                password: proxyPassword,
                persistence: .forSession
            )
            completionHandler(.useCredential, credential)
        } else {
            completionHandler(.performDefaultHandling, nil)
        }
    }
}

// Verwendung mit Geo-Targeting
let delegate = ProxyAuthDelegate(
    username: "user-country-DE-city-berlin-session-xyz789",
    password: "deinPasswort"
)

let proxySession = URLSession(
    configuration: proxyConfig,
    delegate: delegate,
    delegateQueue: nil
)

Die Delegate-Methode ist der empfohlene Ansatz für HTTPS-Verbindungen, da der Proxy-Authorization-Header bei CONNECT-Tunneln nicht immer korrekt weitergeleitet wird.

SOCKS5-Proxy über kCFStreamPropertySOCKSProxy

Für SOCKS5-Verbindungen nutzt ProxyHat Port 1080. Die Konfiguration unterscheidet sich von HTTP-Proxys – Sie verwenden die kCFStreamPropertySOCKSProxy*-Schlüssel:

import Foundation

func makeSOCKS5SessionConfig(proxyHost: String, proxyPort: Int, username: String, password: String) -> URLSessionConfiguration {
    let config = URLSessionConfiguration.default
    
    config.connectionProxyDictionary = [
        // SOCKS5 aktivieren
        kCFStreamPropertySOCKSVersion as String: kCFStreamSocketSOCKSVersion5 as Any,
        kCFStreamPropertySOCKSProxyHost as String: proxyHost,
        kCFStreamPropertySOCKSProxyPort as String: proxyPort,
        kCFStreamPropertySOCKSUser as String: username,
        kCFStreamPropertySOCKSPassword as String: password,
        
        // HTTP/HTTPS-Proxy deaktivieren
        kCFNetworkProxiesHTTPEnable as String: false,
        kCFNetworkProxiesHTTPSEnable as String: false
    ]
    
    return config
}

let socksConfig = makeSOCKS5SessionConfig(
    proxyHost: "gate.proxyhat.com",
    proxyPort: 1080,
    username: "user-country-US-session-abc123",
    password: "deinPasswort"
)

let socksSession = URLSession(configuration: socksConfig)

SOCKS5 ist nützlich, wenn HTTP-CONNECT-Tunnel Probleme verursachen oder wenn Sie Non-HTTP-Traffic tunneln möchten. Beachten Sie, dass SOCKS5-Proxying mit URLSession auf iOS weniger gut dokumentiert ist als HTTP-Proxying – testen Sie dies gründlich auf realen Geräten.

Async/Await mit Residential Proxys: Parallele Anfragen

Für Web-Scraping und SERP-Tracking benötigen Sie oft mehrere parallele Anfragen über verschiedene Proxy-Exit-IPs. Swifts async/await mit TaskGroup ist hier ideal. Das folgende Beispiel ruft JSON-Daten von mehreren Regionen ab und dekodiert sie mit Codable:

import Foundation

// Codable-Modell für die Antwort
struct IPResponse: Codable {
    let origin: String
}

struct ScrapedResult: Codable {
    let url: String
    let status: Int
    let origin: String
}

// Proxy-Konfiguration mit Geo-Targeting pro Region
func makeGeoSession(country: String, session: String) -> URLSession {
    let config = URLSessionConfiguration.default
    
    config.connectionProxyDictionary = [
        kCFNetworkProxiesHTTPEnable as String: true,
        kCFNetworkProxiesHTTPProxy as String: "gate.proxyhat.com",
        kCFNetworkProxiesHTTPPort as String: 8080,
        kCFNetworkProxiesHTTPSEnable as String: true,
        kCFNetworkProxiesHTTPSProxy as String: "gate.proxyhat.com",
        kCFNetworkProxiesHTTPSPort as String: 8080
    ]
    
    config.timeoutIntervalForRequest = 30
    return config
}

func proxyAuthHeader(country: String, sessionId: String) -> String {
    let user = "user-country-\(country)-session-\(sessionId)"
    let pass = "deinPasswort"
    let creds = "\(user):\(pass)"
    return "Basic \(Data(creds.utf8).base64EncodedString())"
}

// Parallele Anfragen über TaskGroup
func scrapeMultipleRegions() async throws -> [ScrapedResult] {
    let regions = [("US", "sess-001"), ("DE", "sess-002"), ("GB", "sess-003"), ("FR", "sess-004"), ("JP", "sess-005")]
    let targetURL = URL(string: "https://httpbin.org/ip")!
    
    return try await withThrowingTaskGroup(of: ScrapedResult.self) { group in
        var results: [ScrapedResult] = []
        
        for (country, sessionId) in regions {
            group.addTask {
                let session = makeGeoSession(country: country, session: sessionId)
                let auth = proxyAuthHeader(country: country, sessionId: sessionId)
                
                var request = URLRequest(url: targetURL)
                request.setValue(auth, forHTTPHeaderField: "Proxy-Authorization")
                request.timeoutInterval = 30
                
                let (data, response) = try await session.data(for: request)
                
                guard let http = response as? HTTPURLResponse else {
                    throw URLError(.badServerResponse)
                }
                
                let ipResp = try JSONDecoder().decode(IPResponse.self, from: data)
                
                return ScrapedResult(
                    url: targetURL.absoluteString,
                    status: http.statusCode,
                    origin: ipResp.origin
                )
            }
        }
        
        for try await result in group {
            results.append(result)
        }
        
        return results
    }
}

// Ausführung
Task {
    do {
        let results = try await scrapeMultipleRegions()
        for r in results {
            print("Status \(r.status) – IP: \(r.origin)")
        }
    } catch {
        print("Scraping fehlgeschlagen: \(error)")
    }
}

Dieses Beispiel erstellt pro Region eine eigene URLSession mit einem eindeutigen Session-Parameter. Die TaskGroup führt alle fünf Anfragen parallel aus, wobei jede über eine andere Exit-IP läuft. Bei 100 gleichzeitigen Sessions sollten Sie die Concurrency begrenzen – URLSessionConfiguration.httpMaximumConnectionsPerHost hilft dabei nicht, da jede Session einen anderen Proxy nutzt.

Proxy-Typen im Vergleich

Produktionstipps: TLS, Retries und ATS

URLSessionDelegate für erweiterte TLS-Kontrolle

In Produktion sollten Sie TLS-Zertifikate validieren und fehlgeschlagene Anfragen mit exponentiellem Backoff wiederholen. Hier ist ein robuster Delegate mit Retry-Logik:

import Foundation

final class ProductionProxyDelegate: NSObject, URLSessionDelegate, URLSessionTaskDelegate {
    let proxyUsername: String
    let proxyPassword: String
    private var attemptCounts: [Int: Int] = [:]
    let maxRetries = 3
    
    init(username: String, password: String) {
        self.proxyUsername = username
        self.proxyPassword = password
    }
    
    // Proxy-Auth bei 407
    func urlSession(
        _ session: URLSession,
        didReceive challenge: URLAuthenticationChallenge,
        completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void
    ) {
        if challenge.protectionSpace.authenticationMethod == NSURLAuthenticationMethodHTTPProxy 
            || challenge.protectionSpace.authenticationMethod == NSURLAuthenticationMethodHTTPSProxy {
            completionHandler(.useCredential, URLCredential(
                user: proxyUsername,
                password: proxyPassword,
                persistence: .forSession
            ))
        } else {
            completionHandler(.performDefaultHandling, nil)
        }
    }
    
    // TLS-Validierung (erweitert mit Logging)
    func urlSession(
        _ session: URLSession,
        didReceive challenge: URLAuthenticationChallenge,
        completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void
    ) {
        if challenge.protectionSpace.authenticationMethod == NSURLAuthenticationMethodServerTrust {
            if let trust = challenge.protectionSpace.serverTrust {
                // Standard-Validierung durchführen
                var error: CFError?
                let isValid = SecTrustEvaluateWithError(trust, &error)
                if isValid {
                    completionHandler(.useCredential, URLCredential(trust: trust))
                } else {
                    print("TLS-Validierung fehlgeschlagen: \(error?.localizedDescription ?? "unbekannt")")
                    completionHandler(.cancelAuthenticationChallenge, nil)
                }
            } else {
                completionHandler(.performDefaultHandling, nil)
            }
        } else {
            completionHandler(.performDefaultHandling, nil)
        }
    }
}

// Retry mit exponentiellem Backoff
func fetchWithRetry(
    url: URL,
    session: URLSession,
    authHeader: String,
    maxAttempts: Int = 3
) async throws -> Data {
    var attempt = 0
    var lastError: Error?
    
    while attempt < maxAttempts {
        do {
            var request = URLRequest(url: url)
            request.setValue(authHeader, forHTTPHeaderField: "Proxy-Authorization")
            
            let (data, response) = try await session.data(for: request)
            
            if let http = response as? HTTPURLResponse, (200...299).contains(http.statusCode) {
                return data
            }
            
            // 429 oder 5xx -> retry
            if let http = response as? HTTPURLResponse,
               http.statusCode == 429 || (500...599).contains(http.statusCode) {
                let delay = pow(2.0, Double(attempt)) // 1s, 2s, 4s
                try await Task.sleep(nanoseconds: UInt64(delay * 1_000_000_000))
                attempt += 1
                continue
            }
            
            return data // Andere Statuscodes zurückgeben
        } catch {
            lastError = error
            let delay = pow(2.0, Double(attempt))
            try await Task.sleep(nanoseconds: UInt64(delay * 1_000_000_000))
            attempt += 1
        }
    }
    
    throw lastError ?? URLError(.timedOut)
}

App Transport Security (ATS)

ATS blockiert standardmäßig unsichere Verbindungen. Da der Proxy selbst über HTTP (nicht HTTPS) erreicht wird, kann ATS Probleme verursachen. In Ihrer Info.plist benötigen Sie möglicherweise eine Ausnahme:

<key>NSAppTransportSecurity</key>
<dict>
    <key>NSAllowsArbitraryLoads</key>
    <true/>
</dict>

Beachten Sie, dass NSAllowsArbitraryLoads die App Store Review stricter macht. Apple verlangt eine Begründung, warum HTTP-Verbindungen notwendig sind. Proxy-Verbindungen zu einem bekannten Gateway sind ein legitimer Grund, aber dokumentieren Sie dies klar.

On-Device Privacy

Speichern Sie Proxy-Credentials niemals im Klartext. Verwenden Sie Keychain Services für die sichere Speicherung:

import Security

func saveProxyCredentials(username: String, password: String) {
    let credentials = "\(username):\(password)"
    let data = Data(credentials.utf8)
    
    let query: [String: Any] = [
        kSecClass as String: kSecClassGenericPassword,
        kSecAttrAccount as String: "proxyhat_credentials",
        kSecValueData as String: data
    ]
    
    SecItemDelete(query as CFDictionary) // Alte Credentials löschen
    SecItemAdd(query as CFDictionary, nil)
}

func loadProxyCredentials() -> (String, String)? {
    let query: [String: Any] = [
        kSecClass as String: kSecClassGenericPassword,
        kSecAttrAccount as String: "proxyhat_credentials",
        kSecReturnData as String: true
    ]
    
    var result: AnyObject?
    let status = SecItemCopyMatching(query as CFDictionary, &result)
    
    guard status == errSecSuccess,
          let data = result as? Data,
          let credentials = String(data: data, encoding: .utf8) else {
        return nil
    }
    
    let parts = credentials.split(separator: ":", maxSplits: 1)
    guard parts.count == 2 else { return nil }
    
    return (String(parts[0]), String(parts[1]))
}

ProxyHat-spezifische Einrichtung

ProxyHat nutzt ein einheitliches Gateway unter gate.proxyhat.com. Die Geo-Targeting- und Session-Parameter werden direkt im Benutzernamen codiert:

• Land: user-country-US:pass@gate.proxyhat.com:8080
• Stadt: user-country-DE-city-berlin:pass@gate.proxyhat.com:8080
• Sticky Session: user-session-abc123:pass@gate.proxyhat.com:8080
• Kombiniert: user-country-US-city-newyork-session-abc123:pass@gate.proxyhat.com:8080

Die vollständige ProxyHat-Dokumentation enthält alle verfügbaren Parameter und Standorte. Die verfügbaren Proxy-Standorte umfassen über 180 Länder. Aktuelle Preise finden Sie auf der Pricing-Seite.

ProxyHat bietet auch SDKs für Python und Node.js, die dasselbe Gateway nutzen. Wenn Ihr Backend-Stack diese Sprachen verwendet, können Sie die Proxy-Logik serverseitig auslagern und die iOS-App nur Ergebnisse abrufen lassen. Dies ist oft sauberer als komplexe Proxy-Logik im Client.

Für SERP-Tracking und Web-Scraping empfiehlt sich ein Hybrider Ansatz: Die iOS-App sendet Anfragen an Ihr Backend, das wiederum über ProxyHat Proxys scrapet. So bleiben Credentials serverseitig und die App muss keine Proxy-Konfiguration enthalten.

Ethik und Rechtliches

Web-Scraping ist legal, wenn Sie öffentlich zugängliche Daten erfassen und die Nutzungsbedingungen der Zielseite respektieren. Im US-Rechtsraum ist der Computer Fraud and Abuse Act (CFAA) relevant – er verbietet unbefugten Zugriff, aber öffentliche Webseiten gelten allgemein als zugänglich. In der EU gilt die DSGVO (GDPR), die personenbezogene Daten schützt. Scrapen Sie keine personenbezogenen Daten ohne Rechtsgrundlage.

Für iOS-Apps gelten zusätzlich die App Store Review Guidelines. Apple verbietet Apps, die andere Apps oder Dienste missbrauchen. Wenn Ihre App Proxy-basiertes Scraping durchführt, stellen Sie sicher, dass dies transparent dokumentiert ist und keine Against-ToS-Aktivitäten stattfinden. Bevorzugen Sie immer offizielle APIs, wenn verfügbar.

Key Takeaways

• connectionProxyDictionary ist der einzige Weg, Proxys in URLSession zu konfigurieren – es gibt keine einfachere API.
• Proxy-Authorization-Header oder URLSessionDelegate sind für die Authentifizierung erforderlich, da kCFProxyUsernameKey unzuverlässig ist.
• Geo-Targeting erfolgt über den Benutzernamen: user-country-US-city-newyork-session-abc123.
• SOCKS5 nutzt kCFStreamPropertySOCKSProxy*-Schlüssel auf Port 1080.
• TaskGroups mit async/await ermöglichen parallele Anfragen über verschiedene Exit-IPs.
• ATS erfordert möglicherweise Ausnahmen in der Info.plist – dokumentieren Sie dies für die App Store Review.
• Keychain ist der richtige Ort für Proxy-Credentials, niemals UserDefaults oder Plaintext.

FAQ

Was bedeutet Proxys in Swift verwenden?

Proxys in Swift verwenden bedeutet, HTTP- oder SOCKS5-Proxys über URLSessionConfiguration.connectionProxyDictionary mit CFNetwork-Konstanten wie kCFNetworkProxiesHTTPEnable und kCFNetworkProxiesHTTPProxy zu konfigurieren. Da URLSession keine eingebaute Proxy-Eigenschaft hat, müssen Entwickler Proxy-Authentifizierung manuell über Proxy-Authorization-Header oder einen URLSessionDelegate implementieren.

Warum ist Proxys in Swift verwenden wichtig für Proxy-Nutzer?

iOS- und macOS-Apps, die auf regionenbeschränkte Endpunkte zugreifen oder Datacenter-IP-Sperren umgehen müssen, benötigen Residential Proxys. Ohne Proxy-Unterstützung in URLSession können Apps keine Anfragen über verschiedene IP-Adressen leiten, was Web-Scraping, SERP-Tracking und geo-basierte Datenabrufe unmöglich macht. Die Proxy-Konfiguration ist daher ein essenzieller Bestandteil für Daten-Engineering auf Apple-Plattformen.

Welcher Proxy-Typ funktioniert am besten für Proxys in Swift?

Residential Proxys sind die beste Wahl für die meisten Anwendungsfälle, da sie echte ISP-IP-Adressen verwenden und von Anti-Bot-Systemen seltener erkannt werden. Mobile Proxys bieten die niedrigste Erkennungsrate, sind aber teurer. Datacenter Proxys sind schnell und günstig, werden aber häufig blockiert. Für URLSession-basierte Apps empfiehlt sich HTTP-Proxy auf Port 8080, da SOCKS5 auf iOS weniger gut dokumentiert ist.

Wie vermeidet man Blocks bei der Implementierung von Proxys in Swift?

Verwenden Sie Residential Proxys mit rotierenden Sessions, setzen Sie realistische Request-Header (User-Agent, Accept-Language), begrenzen Sie die Anfragerate auf 1-2 Requests pro Sekunde pro Session und implementieren Sie exponentielles Backoff bei 429- oder 5xx-Antworten. Verwenden Sie verschiedene Session-IDs pro Anfrage für IP-Rotation und respektieren Sie robots.txt. Vermeiden Sie zu viele gleichzeitige Verbindungen von derselben Session-ID.

Funktioniert Proxy-Authorization-Header auch bei HTTPS-Verbindungen?

Bei HTTPS-Verbindungen verwendet URLSession die HTTP-CONNECT-Methode, um einen Tunnel zum Zielserver aufzubauen. Der Proxy-Authorization-Header wird in der CONNECT-Anfrage gesendet, ist aber nicht immer zuverlässig. Der robustere Ansatz ist die Implementierung von urlSession(_:didReceive:completionHandler:) im URLSessionDelegate, um auf 407-Challenges zu reagieren. Dies funktioniert sowohl für HTTP als auch für HTTPS-Proxy-Verbindungen zuverlässig.