지난주에 407 Proxy Authentication Required 응답 앞에서 한참 시간을 허비했는데, 처음엔 Proxy 공급자가 고장 난 줄 알았습니다. 나중에 보니 로그인 정보를 엉뚱한 속성에 넣어둔 게 원인이었고, 두 줄만 고치면 되는 문제를 찾는 데 두 시간이 걸렸더라고요. 이게 익숙하게 들린다면, 이 가이드는 바로 너를 위해 쓴 겁니다.
C#에서 HttpClient로 Proxy를 설정하는 일은 기본 패턴은 비교적 단순한데, 중간에 숨어 있는 함정들—socket exhaustion, SOCKS5 버전 호환 문제, 그리고 권한 설정에 대한 혼동—이 실제로 많은 시간을 잡아먹습니다.
저는 Thunderbit에서 Web Scraping과 데이터 추출 도구를 오래 다뤄 왔고, 같은 실수가 내부 엔지니어링 논의에서도, 우리가 지켜보는 개발자 커뮤니티에서도 반복해서 나오는 걸 봐 왔습니다. 이 글은 설정, 인증, Proxy rotation, 프로토콜 선택, 그리고 솔직히 말해 처음부터 있었으면 좋았을 디버깅 표까지 전 과정을 다룹니다.
난이도: 초급 ~ 중급
소요 시간: 설명을 따라가는 데 약 15분, production용 Rotation 패턴까지 적용하면 더 걸릴 수 있음
준비물: .NET 6+ SDK (SOCKS5와 최신 handler 기능 지원용; 기본 HTTP proxy 예제는 .NET Framework 4.x도 가능), 코드 에디터, 그리고 테스트할 Proxy endpoint 최소 1개
HttpClient가 뭐고, 왜 굳이 Proxy가 필요한가?
HttpClient는 .NET의 System.Net.Http 안에 있는 기본 클래스라서 HTTP 요청을 보내고 응답을 받는 역할을 합니다. async/await, 사용자 지정 header, cancellation tokens, handler 기반 설정도 지원합니다. Microsoft는 이를 URI로 식별되는 리소스에 HTTP 요청을 보내고 HTTP 응답을 받는 클래스라고 설명합니다.
Proxy 서버는 당신의 애플리케이션과 대상 사이트 사이에 끼어 있는 중간자입니다. 트래픽을 Proxy를 통해 보내면, 대상 사이트는 당신의 IP가 아니라 Proxy의 IP를 보게 됩니다.
HttpClient 자체에는 Proxy 속성이 없습니다. Proxy 라우팅은 하위 handler, 즉 HttpClientHandler나 SocketsHttpHandler에서 설정하고, 이 handler가 WebProxy 인스턴스를 받습니다. 이렇게 생각하면 됩니다:
[당신의 C# 애플리케이션] → [HttpClient + Handler] → [Proxy Server] → [대상 사이트]
그래서 “이미 실행 중인 HttpClient의 Proxy를 바꾼다”는 건 단순히 속성 하나 바꾸는 문제가 아니라 설계 문제입니다. 이건 뒤의 rotation 부분에서 다시 다룰게요.
더 쉽게 데이터를 추출하려면 Thunderbit를 사용해보세요
C#에서 HttpClient에 Proxy를 쓰는 이유
개발자들이 HttpClient 트래픽을 Proxy로 보내는 이유는 꽤 반복적이고, 어떤 Proxy를 써야 하는지는 작업 목적에 따라 달라집니다.
- IP 차단과 rate limit 회피: 대규모 Web Scraping, Lead Generation, 가격 추적에 필수적입니다. 한 IP가 사이트를 계속 두드리면 금방 막힙니다.
- 지역 제한 우회: 특정 국가의 Proxy를 통해 지역 제한이 걸린 API나 콘텐츠에 접근할 수 있습니다.
- 원래 IP 숨기기: 민감한 정보 수집이나 경쟁사 조사에서 추가적인 프라이버시 계층이 됩니다.
- 조직/규정 요구사항: 많은 기업에서는 모든 외부 트래픽이 중앙 Gateway를 거치도록 해서 로그와 통제를 유지합니다.
- 테스트와 QA: 물리적으로 여러 지역에 인프라를 깔지 않고도, 지역별·네트워크별 환경을 흉내 낼 수 있습니다.
| 흔한 용도 | 일반적인 Proxy 유형 | 적합한 이유 |
|---|---|---|
| 대규모 Web scraping | 회전형 Residential proxy | IP 풀이 넓고 안티-봇 시스템에 덜 쉽게 분류됨 |
| e-commerce 가격 추적 | 지역 타겟팅이 가능한 Residential 또는 datacenter proxy | 지역별 가격과 재고를 점검하기 좋음 |
| 고정 Gateway를 통한 API 접근 | Datacenter proxy 또는 corporate proxy | allowlist가 예측 가능하고 비용이 낮음 |
| 기업 규정 준수 | 시스템 Proxy, PAC proxy, 또는 인증이 필요한 corporate proxy | 중앙 로그와 아웃바운드 통제에 유리함 |
| QA 및 로컬라이제이션 테스트 | 국가별 Proxy 풀 | 목표 지역 사용자처럼 접근하는 상황을 재현 가능 |
Proxy 사용도 보통은 비슷한 흐름으로 발전합니다. 처음엔 단일 static Proxy로 라우팅이 제대로 되는지 확인합니다. 운영 중인 Scraper는 여러 Proxy를 풀로 묶고, 대상 도메인, 지역, 실패율 기준으로 요청을 분산합니다. 더 성숙한 팀은 종종 managed Proxy gateway로 옮겨가서 rotation, retries, session affinity를 하나의 endpoint 뒤에서 처리합니다.
하지만 Proxy rotation이 만능은 아닙니다. 대상 사이트가 의심스러운 행동을 차단하고 있다면, IP만 바꾼다고 해결되지 않습니다. 요청 속도, headers, cookies, TLS fingerprinting도 같이 신경 써야 합니다.
어떤 .NET 버전이 무엇을 지원하나: 빠른 호환성 표
블로그에서 본 Proxy 코드를 다른 target framework에 그대로 붙여넣는 건 조용한 실패를 부르는 흔한 원인입니다. 가장 큰 경계선은 .NET Framework 4.x와 현대적인 .NET(.NET 6+) 사이입니다. 어디서 무엇이 되는지 보세요:
| 기능 | .NET Framework 4.x | .NET 6 | .NET 7 | .NET 8–9 |
|---|---|---|---|---|
WebProxy + HttpClientHandler | 예 | 예 | 예 | 예 |
WebProxy("socks5://...")를 통한 SOCKS5 | 아니오 | 예 (.NET 6에 추가) | 예 | 예 |
SocketsHttpHandler (기본 handler) | 아니오 | 예 | 예 | 예 |
HttpClient.DefaultProxy 정적 설정 | 아니오 | 예 | 예 | 예 |
PooledConnectionLifetime | 아니오 | 예 | 예 | 예 |
.NET Framework 4.x를 목표로 한다면, HttpClientHandler와 WebProxy를 사용한 HTTP/HTTPS Proxy에 맞추는 게 좋습니다. SOCKS5 지원과 현대적인 pooling 제어는 .NET 6 이상이 필요합니다.
주의할 만한 미묘한 동작이 하나 더 있습니다. HttpClient.DefaultProxy는 현대 .NET에서 정적 속성입니다. 공통 초기화 코드에서 설정되거나 HTTPS_PROXY, HTTP_PROXY 같은 환경 변수에서 읽혀오면, handler에서 명시적으로 덮어쓰지 않는 한 모든 HttpClient 인스턴스가 그 설정을 따라갑니다. 컨테이너 배포 환경에서 “내가 설정한 적 없는 Proxy를 왜 쓰지?” 같은 상황이 생기는 대표적인 이유입니다.
1단계: C# Console 프로젝트 만들기
터미널을 열고 새 프로젝트를 만듭니다:
dotnet new console -n ProxyHttpClientDemo
cd ProxyHttpClientDemo
dotnet --version으로 SDK 버전을 확인하세요. 이 가이드는 모든 기능을 다루기 위해 .NET 6+를 기준으로 합니다. 최신 LTS가 필요하면 Microsoft 다운로드 페이지에서 받을 수 있습니다.
에디터에서 Program.cs를 여세요. 여기서 모든 작업이 진행됩니다.
2단계: Proxy 없이 기본 HTTP 요청 보내기
Proxy를 설정하기 전에, 먼저 현재 외부 IP가 뭔지 알아두는 게 좋습니다. 그래야 Proxy를 켠 뒤 IP가 정말 바뀌었는지 확인할 수 있습니다.
using System.Net.Http;
using var client = new HttpClient();
var ip = await client.GetStringAsync("https://api.ipify.org/");
Console.WriteLine($"Direct IP: {ip}");
실행해 보세요. 현재 공인 IP가 출력될 겁니다. 예를 들면:
Direct IP: 203.0.113.10
이 값을 기억해 두세요. 다음 단계에서 달라져야 합니다.
3단계: HttpClientHandler에 WebProxy 설정하기
기본 패턴은 WebProxy, handler, client 세 개의 오브젝트로 구성됩니다.
using System.Net;
using System.Net.Http;
var proxy = new WebProxy("http://proxy.example.com:8080")
{
BypassProxyOnLocal = false
};
var handler = new HttpClientHandler
{
Proxy = proxy,
UseProxy = true,
UseDefaultCredentials = false
};
using var client = new HttpClient(handler);
var ip = await client.GetStringAsync("https://api.ipify.org/");
Console.WriteLine($"Proxy IP: {ip}");
proxy.example.com:8080을 실제 Proxy 주소로 바꾸세요. 연결이 제대로 됐다면 출력되는 IP는 당신의 것이 아니라 Proxy exit IP여야 합니다.
중요한 속성은 이렇습니다:
Proxy— handler가 라우팅에 사용하는IWebProxy인스턴스입니다.UseProxy = true— 실제로 Proxy를 사용하겠다는 뜻입니다. 당연해 보여도 이걸 빼먹는 실수가 꽤 많습니다.BypassProxyOnLocal = false— 로컬처럼 보이는 대상에 대해 Proxy를 건너뛰지 않게 합니다.UseDefaultCredentials— Windows 기본 로그인 정보를 보낼지 정합니다. Proxy의 사용자명/비밀번호와는 다른 개념입니다.
4단계: NetworkCredential로 Proxy 인증 추가하기
유료 Proxy 공급자 대부분은 로그인 정보를 요구합니다. 정석은 WebProxy 객체 자체에 credentials를 넣는 것입니다:
using System.Net;
using System.Net.Http;
var proxy = new WebProxy("http://proxy.example.com:8080")
{
Credentials = new NetworkCredential("proxy-user", "proxy-password")
};
var handler = new HttpClientHandler
{
Proxy = proxy,
UseProxy = true
};
using var client = new HttpClient(handler);
var ip = await client.GetStringAsync("https://api.ipify.org/");
Console.WriteLine($"Authenticated proxy IP: {ip}");
많은 공급자가 http://username:password@host:port 형태의 URL을 줍니다. 하지만 .NET 코드에서는 URI 문자열 안에 credentials를 박아 넣는 대신 NetworkCredential을 쓰는 편이 낫습니다. 특수문자가 들어간 비밀번호의 escaping 문제를 피할 수 있고, URI와 credentials의 역할도 명확히 분리됩니다.
뒤에서 가장 흔한 인증 실수와 그것이 왜 407을 만드는지 별도 섹션에서 설명하겠습니다.
5단계: 응답을 읽고 처리하기
단순히 IP 확인만 할 게 아니라, 응답을 제대로 처리해야 합니다:
using var response = await client.GetAsync("https://example.com/api/products");
if (!response.IsSuccessStatusCode)
{
Console.WriteLine($"Request failed: {(int)response.StatusCode} {response.ReasonPhrase}");
return;
}
var body = await response.Content.ReadAsStringAsync();
Console.WriteLine(body);
scraping 작업에서 Proxy를 거친 요청은 전송 계층일 뿐입니다. 결국 parsing, 정규화, deduplication, retries, 그리고 Excel, Google Sheets, database 등으로의 export가 필요합니다. Thunderbit 같은 도구는 추출과 내보내기 단계를 자동화할 수 있고, Chrome 확장 프로그램은 코드로 parsing을 직접 짜지 않아도 구조화된 데이터 추출과 Google Sheets, Excel, Airtable, Notion으로의 무료 export를 지원합니다.
Scraped 데이터를 Excel, Sheets, Airtable, Notion으로 내보내기 Get Started Free
Proxy 로그인 정보와 서버 로그인 정보: 407 오류를 부르는 실수
이 실수는 Stack Overflow 스레드에서도 봤고, Microsoft Q&A 글에서도 봤고, 솔직히 내 코드에서도 봤습니다.
헷갈리기 쉽지만 구분은 단순합니다:
- Proxy credentials는 Proxy 서버 자체에 대한 인증입니다.
- Server credentials는 대상 서버에 대한 인증입니다.
HttpClientHandler에서는 서로 다른 속성에 들어갑니다. 로그인 정보를 잘못된 곳에 넣는 것이 `407 Proxy Authentication Required` 오류의 1순위 원인입니다.
// ❌ 잘못된 예 — 대상 서버 credentials를 설정하고 있고, Proxy용이 아님
handler.Credentials = new NetworkCredential("user", "pass");
// ✅ 올바른 예 — Proxy 객체 자체에 credentials를 설정
handler.Proxy = new WebProxy("http://proxy:8080")
{
Credentials = new NetworkCredential("user", "pass")
};
HttpClientHandler.Credentials는 대상 서버용입니다. WebProxy.Credentials는 Proxy용입니다. Proxy가 407을 반환한다면, credentials는 Proxy 쪽에 있어야 합니다.
또 하나의 함정이 있습니다. HttpClientHandler.PreAuthenticate는 대상 서버 인증의 pre-authentication 동작을 제어할 뿐입니다. Proxy-Authorization 헤더를 제어하지 않습니다. 407 해결책으로 쓰면 안 됩니다.
C#에서 Proxy rotation을 어떻게 하나?
이 질문은 포럼에서 정말 자주 나옵니다. 초반의 답은 조금 실망스러울 수 있지만, 핵심은 이겁니다: 이미 실행 중인 HttpClient 인스턴스의 Proxy는 바꿀 수 없습니다. Proxy는 handler에 붙어 있고, handler는 생성 시점에 고정됩니다. HttpClient 자체에는 바꿀 수 있는 Proxy 속성이 없습니다.
“그럼 요청마다 new HttpClient(new HttpClientHandler { Proxy = ... })를 만들면 되겠네?”라고 생각하기 쉽지만, 그건 또 다른 문제를 만듭니다. Microsoft는 요청마다 client를 생성하고 닫는 방식이 TCP 포트를 고갈시킬 수 있다고 명시적으로 경고합니다. 연결이 닫힌 직후 포트가 바로 해제되지 않기 때문입니다.
그래서 production에서 잘 먹히는 패턴은 아래 세 가지입니다.
옵션 1: IHttpClientFactory의 named client 사용
Proxy 풀의 구성이 시작 시점에 이미 정해져 있다면, named client가 가장 단순합니다. 각 named client는 자기만의 handler 설정을 갖고, 애플리케이션은 런타임에 이름으로 꺼내 씁니다.
builder.Services.AddHttpClient("proxy-us")
.ConfigurePrimaryHttpMessageHandler(() => new HttpClientHandler
{
Proxy = new WebProxy("http://us-proxy.example.com:8080")
{
Credentials = new NetworkCredential("user", "pass")
},
UseProxy = true
});
builder.Services.AddHttpClient("proxy-eu")
.ConfigurePrimaryHttpMessageHandler(() => new HttpClientHandler
{
Proxy = new WebProxy("http://eu-proxy.example.com:8080")
{
Credentials = new NetworkCredential("user", "pass")
},
UseProxy = true
});
// 요청할 때:
var client = httpClientFactory.CreateClient("proxy-us");
factory가 handler 수명을 관리하므로, 요청마다 client를 새로 만드는 안티패턴을 피할 수 있습니다.
옵션 2: SocketsHttpHandler + PooledConnectionLifetime (.NET 6+)
장수하는 client를 쓰고 있고, rotating Proxy gateway가 새 연결마다 exit IP를 바꿔준다면 PooledConnectionLifetime을 이용해 일정 시간이 지나면 새 연결을 만들게 할 수 있습니다.
var handler = new SocketsHttpHandler
{
Proxy = new WebProxy("http://rotating-gateway.example.com:8080")
{
Credentials = new NetworkCredential("user", "pass")
},
UseProxy = true,
PooledConnectionLifetime = TimeSpan.FromMinutes(5)
};
using var client = new HttpClient(handler);
이게 Proxy 오브젝트를 요청마다 마법처럼 바꾸는 건 아닙니다. 새 TCP 연결마다 다른 IP를 배정하는 Proxy gateway나, hostname이 시간에 따라 다른 곳으로 해석되는 pool형 Proxy와 잘 맞습니다.
옵션 3: 고급 Proxy 선택용 커스텀 DelegatingHandler
요청 URL, payload, 실행 컨텍스트에 따라 Proxy를 골라야 한다면, 커스텀 handler가 각 요청을 검사해서 inner handler의 적절한 경로로 보낼 수 있습니다.
public sealed class ProxyRoutingHandler : DelegatingHandler
{
private readonly IReadOnlyDictionary<string, HttpMessageInvoker> _clients;
protected override Task<HttpResponseMessage> SendAsync(
HttpRequestMessage request,
CancellationToken cancellationToken)
{
var key = SelectProxyKey(request);
return _clients[key].SendAsync(request, cancellationToken);
}
}
이건 꽤 고급 설계입니다. thread safety, disposal, handler 재사용, retry 동작, logging까지 전부 직접 책임져야 합니다. 앞의 두 가지가 정말 안 맞을 때만 추천합니다.
세 가지 방식 비교
| 방식 | 복잡도 | .NET 버전 | thread-safe | 오버헤드 |
|---|---|---|---|---|
| named client (IHttpClientFactory) | 낮음 | .NET Core 2.1+ | 높음(불변 설정) | 낮음 |
| SocketsHttpHandler + PooledConnectionLifetime | 중간 | .NET 6+ | 높음 | 낮음 |
| Custom DelegatingHandler | 높음 | 모든 버전 | 구현에 따라 다름 | 중간 |
대부분의 팀에는 named client가 시작점으로 가장 좋습니다. 안정적인 rotating gateway라면 PooledConnectionLifetime로 가고, 요청 메타데이터에 따라 Proxy를 골라야 하는 경우에만 커스텀 라우팅을 쓰세요.
올바른 Proxy 프로토콜 선택: HTTP, HTTPS, SOCKS5
모든 Proxy가 같은 말을 하는 건 아니고, 프로토콜을 잘못 고르면 이해하기 어려운 오류가 납니다.
HTTP proxy: HTTP 요청을 이해합니다. 일반적인 HTTP 대상에는 직접 전달할 수 있고, HTTPS 대상에는 클라이언트가 CONNECT 요청을 보내 tunnel을 만든 뒤 그 tunnel을 통해 TLS 협상을 진행합니다. 가장 흔한 방식입니다.
HTTPS-terminating proxy: Proxy가 자기 TLS 인증서를 내세우고, 나가는 트래픽을 다시 암호화합니다. 기업용 inspection 시스템이나 일부 managed scraping API에서 흔합니다. 클라이언트가 Proxy의 인증서 체인을 신뢰하지 않으면 인증서 오류가 날 수 있습니다.
SOCKS5 proxy: HTTP에만 한정되지 않고 TCP 트래픽 전체를 터널링하는 전송 계층 Proxy입니다. Residential proxy 공급자들에서 자주 쓰입니다. .NET 6+에서 기본 지원됩니다.
SOCKS5 예시:
var handler = new SocketsHttpHandler
{
Proxy = new WebProxy("socks5://proxy.example.com:1080")
{
Credentials = new NetworkCredential("proxy-user", "proxy-password")
},
UseProxy = true
};
using var client = new HttpClient(handler);
var ip = await client.GetStringAsync("https://api.ipify.org/");
Console.WriteLine(ip);
SSL 인증서 검증에 대한 참고
HTTPS termination Proxy를 쓰면 RemoteCertificateNameMismatch 오류가 보일 수 있습니다. 이때는 ServerCertificateCustomValidationCallback으로 검증을 조정할 수 있습니다:
var handler = new HttpClientHandler
{
ServerCertificateCustomValidationCallback =
HttpClientHandler.DangerousAcceptAnyServerCertificateValidator
};
이건 로컬 개발 환경이나, 신뢰할 수 있고 승인된 TLS-intercepting Proxy에서만 써야 합니다. 무조건 true를 반환하면 중요한 보안 검사가 꺼지고 man-in-the-middle 공격에 취약해집니다. production에서는 일반 CONNECT 또는 SOCKS Proxy를 쓸 때 SSL 검증을 켜 두세요.
C# HttpClient Proxy에서 자주 나오는 문제 해결
아래 표는 겉으로 보이는 증상, 가장 가능성 높은 원인, 그리고 먼저 해볼 수정 방법을 연결해 줍니다. 이 부분은 즐겨찾기에 넣어둘 만합니다. Stack Overflow 스레드와 개발자 포럼에서 가장 자주 보이는 오류들을 거의 다 다룹니다.
| 오류 / 증상 | 흔한 원인 | 먼저 해볼 수정 |
|---|---|---|
| 407 Proxy Authentication Required | credentials를 handler.Credentials에 넣고 handler.Proxy.Credentials에 넣지 않음; 사용자 포맷 오류; URL에 직접 넣은 비밀번호의 특수문자 문제 | WebProxy.Credentials = new NetworkCredential(...) 사용; URI에 credentials를 넣지 않기; 공급자 사용자 포맷 확인 |
| TaskCanceledException / Timeout | Proxy endpoint가 느리거나, 닿지 않거나, 과부하 상태이거나, firewall에 막힘; 기본 100초 timeout이 너무 짧음 | 먼저 curl로 Proxy를 확인; endpoint가 정상인지 확인한 뒤에만 HttpClient.Timeout 늘리기; retries와 health check 추가 |
| SocketException / Socket exhaustion | 요청마다 HttpClient나 handler를 새로 만들고 닫음 | IHttpClientFactory, singleton client, 또는 pooling 제어가 있는 SocketsHttpHandler 사용 |
| SSL RemoteCertificateNameMismatch | 기업용 또는 managed Proxy가 HTTPS를 가로채는 경우 | Proxy의 CA를 설치/승인; 검증 무력화는 통제된 개발 환경이나 승인된 MITM 시나리오에서만 사용 |
| 302 Redirect loop | corporate Proxy/VPN의 captive portal이 계속 redirect하거나 allowlist 차단이 반복됨 | 직접 연결 테스트; Location header 확인; Proxy 포털의 allowlist와 인증 확인 |
| HttpRequestException / No connection with SOCKS URL | SOCKS 코드를 .NET Framework나 더 오래된 .NET에서 실행; scheme 또는 port가 틀림 | SOCKS 기본 지원은 .NET 6+에서 사용; socks5://host:port 확인; 공급자 문서 대조 |
| Proxy가 적용되지 않는 것처럼 보임 | UseProxy = false; 대상이 local로 간주되어 우회됨; NO_PROXY 환경 변수; handler가 생각한 것과 다르게 설정됨 | UseProxy = true로 설정; HttpClient.DefaultProxy 확인; 환경 변수 정리 또는 덮어쓰기; BypassProxyOnLocal = false 설정 |
빠른 디버깅 흐름
- 요청이 성공했는가? → 그렇다면
api.ipify.org결과가 예상한 Proxy IP와 같은지 확인하세요. - 아니고 HTTP status code가 있는가? → 407이면 Proxy credentials를 고치세요. 403/429면 대상이 Proxy를 막거나 rate limit을 건 겁니다. 3xx 루프면 Proxy나 corporate gateway가 redirect를 일으킬 수 있습니다.
- status code 없이 exception만 있는가? → Timeout이면 Proxy 도달성을 확인하세요. Socket/Certificate 예외면 pooling, 프로토콜, TLS, .NET 버전을 점검하세요.
.NET 밖에서 Proxy를 먼저 시험해 볼 때 유용한 명령어:
curl -x http://user:pass@proxy.example.com:8080 https://api.ipify.org/
curl --socks5 user:pass@proxy.example.com:1080 https://api.ipify.org/
curl은 되는데 C# 코드는 안 된다면, 보통 authentication scheme, TLS trust store, 환경 변수, credentials escaping 중 하나가 다릅니다. curl의 Proxy 주소, scheme, auth를 정확히 맞춘 뒤, credentials만 NetworkCredential로 옮기세요.
Proxy 관리를 아예 건너뛰는 게 나을 때: 코드 없는 대안
“HttpClient proxy C#”을 찾는 많은 개발자는 사실 Proxy 이론을 배우려는 게 아니라, scraper를 계속 돌아가게 만들고 싶은 겁니다. C# 커스텀 코드가 맞는 경우와 아닌 경우를 솔직하게 구분할 필요가 있습니다.
다음과 같은 경우에는 C# + Proxy rotation으로 직접 scraper를 만드세요:
- 요청 로직, cookies, headers, retries, parsing을 완전히 제어해야 할 때
- 기존 .NET 코드베이스나 내부 서비스에 scraper를 붙여야 할 때
- 보안이나 규정상 인프라 전체를 직접 소유해야 할 때
다음과 같은 경우에는 Thunderbit 같은 no-code 도구를 쓰세요:
- 목적이 HTTP 인프라가 아니라 웹사이트에서 구조화된 데이터 추출일 때
- Proxy 풀 관리, CAPTCHA 대응, socket exhaustion 디버깅을 하고 싶지 않을 때
- 팀이 코드 없이 Excel, Google Sheets, Airtable, Notion으로 바로 데이터를 받고 싶을 때
Thunderbit의 Chrome 확장 프로그램은 cloud scraping 옵션을 통해 Proxy rotation과 안티-봇 대응을 자동으로 처리합니다. API를 쓰면 개발자는 JSON schema만 정의하고 구조화된 데이터를 돌려받을 수 있어서, HttpClient나 WebProxy를 전혀 직접 관리하지 않아도 됩니다. 가격 비교용 web scraping이나 리드 추출을 하는 팀에게는 초기 설정 시간을 크게 줄여 줍니다.
| 상황 | C# 맞춤 개발 + Proxy | Thunderbit |
|---|---|---|
| 요청 로직을 완전히 통제해야 함 | 예 | 아니오(API 수준 제어) |
| Proxy 관리 필요 | 예 | 아니오(자동 처리) |
| Anti-bot / CAPTCHA 대응 | 수동 또는 외부 도구 | 내장 |
| 설정 시간 | 몇 시간 ~ 며칠 | 몇 분 |
| 가장 적합한 대상 | 기존 .NET 코드베이스, 맞춤형 pipeline | 빠른 데이터 추출, 비기술 팀, 스프레드시트 내보내기 |
이건 “절대 HttpClient를 쓰지 마라”는 말이 아닙니다. production .NET 서비스를 만든다면 Proxy 설정을 이해하는 건 정말 중요합니다. 하지만 단발성 데이터 수집 작업 때문에 407 오류를 몇 시간씩 디버깅하고 있다면, 더 단순한 선택지도 분명히 있습니다. 그걸 써도 괜찮습니다. Thunderbit 가격을 보거나 YouTube 채널에서 튜토리얼을 확인해 보세요.
핵심 요점
기본 패턴은 여전히 같습니다: WebProxy → handler → HttpClient. 그 뒤에 오는 건 결국 production에서 부딪히는 운영 문제를 다루는 일입니다.
- credentials는 handler가 아니라 Proxy에 넣어야 합니다. 407 섹션의 대비 예제가 가장 중요한 기억 포인트입니다.
- 요청마다, 또는 Proxy마다
HttpClient를 새로 만들지 마세요. named client용IHttpClientFactory, rotating gateway용PooledConnectionLifetime가 있는SocketsHttpHandler, 또는 고급 시나리오용 custom routing handler를 쓰세요. - SOCKS5나
SocketsHttpHandler코드를 복붙하기 전에 .NET 버전을 확인하세요. 위의 호환성 표가 조용한 실패를 많이 막아줍니다. - 먼저 .NET 밖에서 Proxy를 테스트하세요. 짧은
curl명령 하나가 디버깅의 큰 부분을 줄여 줍니다. - Proxy 스트레스 없이 구조화된 데이터를 추출하고 싶다면, Thunderbit 같은 도구가 전송 계층을 대신 처리해 주므로 데이터 자체에 집중할 수 있습니다.
다음에 407이나 TaskCanceledException을 만나면, 위의 문제 해결 표부터 보세요.
자주 묻는 질문
기존 HttpClient 인스턴스의 Proxy를 바꿀 수 있나요?
아니요. Proxy는 handler에 묶여 있고, handler는 생성 시점에 결정됩니다. HttpClient에는 바꿀 수 있는 Proxy 속성이 없습니다. 서로 다른 Proxy가 필요하면 별도의 handler와 client를 만들고, IHttpClientFactory의 named client나 미리 구성한 client pool로 관리해야 합니다.
HttpClient는 기본적으로 시스템 Proxy를 사용하나요?
네. 현대 .NET에서는 handler를 명시적으로 설정하지 않으면 HttpClient가 HTTPS_PROXY, HTTP_PROXY 같은 환경 변수를 포함한 시스템 기본 Proxy 설정을 HttpClient.DefaultProxy를 통해 상속합니다. 이를 끄려면 handler에서 UseProxy = false를 명시하세요.
C#의 HttpClient에서 SOCKS5 proxy를 어떻게 쓰나요?
new WebProxy("socks5://host:port")와 SocketsHttpHandler를 함께 써야 합니다. SOCKS proxy의 기본 지원은 .NET 6 이상이 필요합니다. .NET Framework 4.x에는 SOCKS5 기본 지원이 없어서 서드파티 라이브러리가 필요합니다.
왜 계속 407 Proxy Authentication Required가 뜨나요?
대부분 handler.Credentials에 credentials를 넣었는데 handler.Proxy.Credentials에 넣지 않았기 때문입니다. 위의 “Proxy 로그인 정보와 서버 로그인 정보” 섹션을 보면 올바른 패턴을 바로 확인할 수 있습니다.
Proxy를 쓸 때 SSL 인증서 검증을 꺼도 안전한가요?
로컬 개발 환경이거나, 완전히 신뢰하는 Proxy 공급자일 때만 그렇습니다. 예를 들어 HTTPS proxy 모드의 managed scraping API 같은 경우가 그 예입니다. production에서는 일반 CONNECT나 SOCKS Proxy를 쓸 때 SSL 검증을 켜 두어 man-in-the-middle 공격을 막아야 합니다.
Thunderbit로 손쉽게 Web Scraping 시작하기 Get Started Free
더 읽을거리
