지난주에는 407 Proxy Authentication Required 응답만 멍하니 바라보며, 프록시 제공업체에 문제가 생긴 줄 알고 한참을 허비했습니다. 알고 보니 자격 증명을 잘못된 속성에 넣어둔 게 원인이었고, 고치는 데 걸린 시간은 단 두 줄, 하지만 찾는 데만 두 시간이 걸렸죠. 비슷한 경험이 있다면, 이 글이 딱 맞습니다.
C#에서 HttpClient에 프록시를 설정하는 일은 겉보기에는 단순하지만, 실제 운영 환경에서는 소켓 고갈, SOCKS5 버전 불일치, 인증 정보 혼동 같은 함정이 시간을 잡아먹기 쉽습니다.
저는 Thunderbit에서 웹 스크래핑과 데이터 추출 도구를 다루며 이런 문제를 꽤 오래 접해왔고, 사내 엔지니어링 논의는 물론 개발자 커뮤니티에서도 같은 실수를 반복해서 봐왔습니다. 이 가이드에서는 초기 설정부터 인증, 프록시 회전, 프로토콜 선택, 그리고 제가 처음부터 있었으면 정말 좋았겠다고 생각했던 문제 해결 표까지 한 번에 정리합니다.
난이도: 초급~중급
소요 시간: 따라 해보는 데 약 15분, 운영 환경의 회전 패턴까지 포함하면 더 오래 걸릴 수 있음
준비물: .NET 6 이상 SDK(SOCKS5와 최신 핸들러 기능을 위해; 기본 HTTP 프록시 예시는 .NET Framework 4.x에서도 가능), 코드 편집기, 테스트할 프록시 엔드포인트 1개 이상
HttpClient란 무엇이고, 왜 프록시가 필요한가?
HttpClient는 System.Net.Http에 포함된 .NET 기본 클래스이며, HTTP 요청을 보내고 응답을 받는 데 사용합니다. async/await, 사용자 지정 헤더, 취소 토큰, 핸들러 기반 설정을 지원합니다. Microsoft는 이를 URI로 식별되는 리소스에서 HTTP 요청을 보내고 HTTP 응답을 받기 위한 클래스라고 설명합니다.
프록시 서버는 애플리케이션과 대상 웹사이트 사이에 들어가는 중개자입니다. 트래픽을 프록시를 통해 보내면, 대상 사이트는 사용자의 IP가 아니라 프록시의 IP를 보게 됩니다.
HttpClient 자체에는 Proxy 속성이 없습니다. 프록시 라우팅은 아래쪽 핸들러, 즉 HttpClientHandler 또는 SocketsHttpHandler에 설정하며, 이 핸들러는 WebProxy 인스턴스를 받습니다. 구조를 그림으로 보면 이렇습니다.
[Your C# App] → [HttpClient + Handler] → [Proxy Server] → [Target Website]
그래서 “실행 중인 HttpClient의 프록시를 바꾼다”는 건 단순한 속성 변경이 아니라 설계 문제입니다. 이 부분은 회전(rotate) 섹션에서 더 자세히 다룹니다.
C#에서 HttpClient와 함께 프록시를 사용하는 이유
개발자들이 HttpClient 트래픽을 프록시로 우회시키는 이유는 자주 반복되는 몇 가지가 있고, 업무에 따라 적합한 프록시 유형도 달라집니다.
- IP 차단과 속도 제한 회피: 대규모 웹 스크래핑, 리드 생성, 가격 모니터링에 필수입니다. 하나의 IP가 사이트를 계속 두드리면 금방 차단됩니다.
- 지역 제한 우회: 특정 국가의 프록시를 통해 지역 잠금 API나 콘텐츠에 접근할 수 있습니다.
- 원 IP 보호: 민감한 데이터 수집이나 경쟁사 조사에서 한층 더 안전하게 처리할 수 있습니다.
- 기업/컴플라이언스 요구사항: 많은 기업은 로깅과 거버넌스를 위해 모든 외부 트래픽을 중앙 게이트웨이를 통해 보내도록 요구합니다.
- 테스트와 QA: 실제로 인프라를 그 지역에 배포하지 않아도, 여러 위치나 네트워크 조건에서 오는 요청을 시뮬레이션할 수 있습니다.
| 사용 사례 | 일반적인 프록시 선택 | 적합한 이유 |
|---|---|---|
| 대규모 웹 스크래핑 | 회전형 주거용 프록시 | IP 다양성이 높아 봇 차단 시스템이 식별하기 어려움 |
| 이커머스 가격 모니터링 | 주거용 또는 지역 타깃형 데이터센터 프록시 | 지역별 가격 및 재고 확인에 유리 |
| 고정 게이트웨이를 통한 API 접근 | 데이터센터 프록시 또는 기업 프록시 | 예측 가능한 IP 허용 목록 관리, 낮은 비용 |
| 엔터프라이즈 컴플라이언스 | 시스템 프록시, PAC 프록시, 인증된 회사 프록시 | 중앙 집중식 로깅 및 외부 트래픽 제어 |
| QA 및 로컬라이제이션 테스트 | 국가별 프록시 풀 | 목표 지역의 실제 사용자 접근을 모사 |
프록시 사용은 보통 단계적으로 확장됩니다. 처음에는 단일 고정 프록시로 라우팅이 되는지 확인하고, 운영용 스크래퍼는 대상 도메인, 지역, 실패율에 따라 요청을 여러 프록시로 분배하는 풀 구조로 발전합니다. 성숙한 팀은 회전, 재시도, 세션 유지까지 하나의 엔드포인트 뒤에서 관리되는 프록시 게이트웨이로 옮겨가기도 합니다.
프록시 회전이 만능 해결책은 아닙니다. 대상 사이트가 수상한 행동을 차단하는 경우, IP만 바꾼다고 해결되지 않고 요청 빈도, 헤더, 쿠키, TLS 지문까지 함께 신경 써야 합니다.
어떤 .NET 버전이 무엇을 지원할까: 간단 호환성 표
블로그 글에서 복사한 프록시 코드를 잘못된 타깃 프레임워크에 넣는 일은 조용한 실패의 대표 원인입니다. 가장 큰 경계선은 .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(기본 핸들러) | 아니오 | 예 | 예 | 예 |
HttpClient.DefaultProxy 정적 속성 | 아니오 | 예 | 예 | 예 |
PooledConnectionLifetime | 아니오 | 예 | 예 | 예 |
.NET Framework 4.x를 대상으로 한다면, HttpClientHandler와 WebProxy를 사용한 HTTP/HTTPS 프록시로 제한하는 것이 좋습니다. SOCKS5와 최신 풀링 제어는 .NET 6 이상이 필요합니다.
주의할 미묘한 동작도 있습니다. 최신 .NET의 HttpClient.DefaultProxy는 정적 속성입니다. 공유 시작 코드에서 설정되었거나 HTTPS_PROXY, HTTP_PROXY 같은 환경 변수에서 상속되면, 핸들러를 명시적으로 덮어쓰지 않는 한 모든 HttpClient 인스턴스가 이를 따라갑니다. 컨테이너 환경에서는 “내가 설정하지 않은 프록시를 왜 쓰지?”라는 혼란의 원인이 자주 됩니다.
1단계: 새 C# 콘솔 프로젝트 만들기
터미널을 열고 새 프로젝트를 생성합니다.
dotnet new console -n ProxyHttpClientDemo
cd ProxyHttpClientDemo
dotnet --version으로 SDK 버전을 확인하세요. 이 가이드의 예시는 전체 기능을 다루기 위해 .NET 6 이상을 기준으로 합니다. 최신 LTS SDK가 필요하다면 Microsoft 다운로드 페이지에서 받을 수 있습니다.
편집기에서 Program.cs를 여세요. 이제부터 핵심 작업이 이 파일에서 진행됩니다.
2단계: 프록시 없이 기본 HTTP 요청 보내기
프록시를 설정하기 전에, 먼저 실제 외부 IP를 확인해 두세요. 그래야 프록시를 켠 뒤 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, 핸들러, 클라이언트 이렇게 세 객체를 사용하는 방식입니다.
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 부분은 실제 프록시 엔드포인트로 바꾸세요. 설정이 올바르면 출력되는 IP는 실제 IP가 아니라 프록시의 출구 IP와 일치해야 합니다.
핵심 속성은 다음과 같습니다.
Proxy— 핸들러가 라우팅에 사용하는IWebProxy인스턴스입니다.UseProxy = true— 설정한 프록시를 실제로 사용하도록 지시합니다. 당연해 보이지만, 이걸 빼먹으면 꽤 오래 헤맬 수 있습니다.BypassProxyOnLocal = false— 로컬처럼 보이는 대상에 대해 프록시를 건너뛰지 못하게 합니다.UseDefaultCredentials— Windows 기본 자격 증명을 보낼지 여부를 제어합니다. 이 값은 프록시 사용자 이름/비밀번호와는 별개입니다.
4단계: NetworkCredential로 프록시 인증 추가하기
대부분의 유료 프록시 제공업체는 인증 정보를 요구합니다. 올바른 패턴은 WebProxy 객체 자체에 자격 증명을 설정하는 것입니다.
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 문자열 안에 자격 증명을 넣기보다 NetworkCredential을 사용하는 편이 좋습니다. 비밀번호에 특수 문자가 들어가도 이스케이프 문제를 줄일 수 있고, URI와 자격 증명의 역할도 명확히 구분됩니다.
가장 흔한 인증 실수, 그리고 왜 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);
스크래핑 워크플로에서는 프록시 요청이 전송 계층에 불과합니다. 그 뒤에는 파싱, 정규화, 중복 제거, 재시도, 그리고 Excel, Google Sheets, 데이터베이스 등으로의 내보내기까지 필요합니다. Thunderbit 같은 도구는 추출과 내보내기 단계를 자동화할 수 있습니다. Chrome 확장 프로그램을 사용하면 구조화 데이터 추출과 Google Sheets, Excel, Airtable, Notion으로의 무료 내보내기를 위해 직접 파싱 코드를 작성할 필요가 없습니다.
스크래핑한 데이터를 Excel, Sheets, Airtable, Notion으로 내보내기 Get Started Free
프록시 자격 증명과 서버 자격 증명: 407 오류를 만드는 흔한 실수
이 실수는 Stack Overflow 질문, Microsoft Q&A 글, 그리고 솔직히 제 코드에서도 본 적이 있습니다.
구분은 간단하지만 헷갈리기 쉽습니다.
- 프록시 자격 증명은 프록시 서버 자체에 인증할 때 사용합니다.
- 서버 자격 증명은 대상 서버에 인증할 때 사용합니다.
HttpClientHandler에서는 이 둘이 서로 다른 속성에 들어갑니다. 잘못된 곳에 넣으면 407 Proxy Authentication Required 오류의 가장 흔한 원인 중 하나가 됩니다.
// ❌ 잘못된 예 — 프록시가 아니라 대상 서버용 자격 증명을 설정함
handler.Credentials = new NetworkCredential("user", "pass");
// ✅ 올바른 예 — 프록시 객체 자체에 자격 증명을 설정함
handler.Proxy = new WebProxy("http://proxy:8080")
{
Credentials = new NetworkCredential("user", "pass")
};
HttpClientHandler.Credentials는 대상 서버를 가리킵니다. WebProxy.Credentials는 프록시를 가리킵니다. 프록시가 407을 반환한다면, 자격 증명은 프록시 쪽에 넣어야 합니다.
또 하나의 함정은 HttpClientHandler.PreAuthenticate입니다. 이 속성은 대상 서버 인증에 대한 사전 인증 동작만 제어합니다. Proxy-Authorization 헤더를 처리하지는 않으므로, 407 해결책으로 쓰면 안 됩니다.
C#의 HttpClient에서 프록시를 회전시키는 방법
이 질문은 포럼에서 정말 자주 나옵니다. 답은 처음엔 실망스러울 수 있지만 중요합니다. 실행 중인 HttpClient 인스턴스의 프록시는 바꿀 수 없습니다. 프록시는 핸들러에 묶여 있고, 핸들러는 생성 시점에 정해집니다. HttpClient에는 변경 가능한 Proxy 속성이 없습니다.
무심코 new HttpClient(new HttpClientHandler { Proxy = ... })를 요청마다 새로 만드는 방식은 다른 문제를 만듭니다. Microsoft는 요청마다 클라이언트와 핸들러를 만들고 버리는 패턴이 사용 가능한 TCP 포트를 고갈시킬 수 있다고 명시적으로 경고합니다. 연결을 닫아도 포트가 즉시 해제되지 않기 때문입니다.
따라서 실제 운영에서 잘 작동하는 패턴은 다음 세 가지입니다.
옵션 1: IHttpClientFactory의 이름 지정 클라이언트
프록시 세트가 시작 시점에 이미 정해져 있다면, 이름 지정 클라이언트가 가장 단순한 선택입니다. 각 이름 지정 클라이언트는 자신만의 핸들러 구성을 가지며, 애플리케이션 코드는 런타임에 이름으로 꺼내 쓰면 됩니다.
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");
팩토리가 핸들러 수명을 관리하므로, 요청마다 클라이언트를 새로 만드는 안티패턴을 피할 수 있습니다.
옵션 2: SocketsHttpHandler + PooledConnectionLifetime (.NET 6+)
새 연결이 생길 때마다 출구 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를 할당하는 프록시 게이트웨이, 또는 시간이 지나면서 서로 다른 엔드포인트로 해석되는 DNS 기반 프록시 풀과 잘 맞습니다.
옵션 3: 고급 프록시 선택을 위한 커스텀 DelegatingHandler
프록시 선택이 요청 URL, 페이로드, 실행 시점 컨텍스트에 따라 달라진다면, 커스텀 라우팅 핸들러가 각 요청을 검사해 올바른 내부 핸들러 파이프라인으로 넘길 수 있습니다.
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);
}
}
이건 고급 설계입니다. 스레드 안전성, 정리(disposal), 핸들러 재사용, 재시도 동작, 로깅까지 모두 직접 책임져야 합니다. 앞의 두 방법이 정말 맞지 않을 때만 권합니다.
세 가지 접근 방식 비교
| 접근 방식 | 복잡도 | .NET 버전 | 스레드 안전성 | 오버헤드 |
|---|---|---|---|---|
| 이름 지정 클라이언트(IHttpClientFactory) | 낮음 | .NET Core 2.1+ | 높음(불변 설정) | 낮음 |
| SocketsHttpHandler + PooledConnectionLifetime | 중간 | .NET 6+ | 높음 | 낮음 |
| 커스텀 DelegatingHandler | 높음 | 제한 없음 | 구현에 따라 다름 | 중간 |
대부분의 팀에는 이름 지정 클라이언트가 출발점으로 가장 좋습니다. 안정적인 회전형 게이트웨이라면 PooledConnectionLifetime으로 넘어가고, 프록시 선택이 요청 단위 메타데이터에 따라 달라질 때만 커스텀 라우팅을 고려하세요.
올바른 프록시 프로토콜 고르기: HTTP, HTTPS, SOCKS5
모든 프록시가 같은 언어를 쓰는 것은 아닙니다. 잘못된 프로토콜 스킴을 쓰면 이해하기 어려운 오류가 생깁니다.
HTTP 프록시: HTTP 요청을 이해합니다. 일반 HTTP 대상에는 직접 전달할 수 있고, HTTPS 대상에는 클라이언트가 CONNECT 요청으로 터널을 만든 뒤 그 터널 안에서 TLS 협상이 이뤄집니다. 가장 흔한 모델입니다.
HTTPS 종료형 프록시: 프록시가 자체 TLS 인증서를 제시하고 상위 트래픽을 다시 암호화합니다. 기업용 검사 시스템이나 일부 관리형 스크래핑 API에서 흔합니다. 클라이언트가 프록시 인증서 체인을 신뢰하지 않으면 인증서 검증 오류가 날 수 있습니다.
SOCKS5 프록시: HTTP에만 국한되지 않고 모든 TCP 트래픽에 동작하는 전송 계층 터널입니다. 주거용 프록시 제공업체에서 널리 쓰입니다. .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 종료형 프록시를 사용할 때 RemoteCertificateNameMismatch 오류가 보일 수 있습니다. ServerCertificateCustomValidationCallback으로 검증 방식을 바꿀 수 있습니다.
var handler = new HttpClientHandler
{
ServerCertificateCustomValidationCallback =
HttpClientHandler.DangerousAcceptAnyServerCertificateValidator
};
이 코드는 로컬 개발 환경이나, 신뢰하고 승인된 TLS 인터셉팅 프록시에서만 사용하세요. 무조건 true를 반환하면 중요한 보안 검사를 꺼버리게 되며, 중간자 공격에 취약해집니다. 일반적인 CONNECT 또는 SOCKS 프록시를 운영 환경에서 사용할 때는 SSL 검증을 유지하세요.
C# HttpClient에서 자주 발생하는 프록시 오류 해결하기
이 표는 눈에 보이는 증상과 가능한 원인, 그리고 가장 먼저 시도할 해결책을 매칭합니다. Stack Overflow 질문과 개발자 포럼에서 가장 자주 보이는 오류를 중심으로 정리했으니, 북마크해 두면 좋습니다.
| 오류 / 증상 | 흔한 원인 | 해결 방법 |
|---|---|---|
| 407 Proxy Authentication Required | 자격 증명을 handler.Proxy.Credentials가 아니라 handler.Credentials에 넣음; 사용자 이름 형식이 잘못됨; URL에 직접 넣은 비밀번호에 특수문자가 포함됨 | WebProxy.Credentials = new NetworkCredential(...) 사용; URI에 자격 증명을 직접 넣지 않기; 제공업체의 사용자 이름 형식 확인 |
| TaskCanceledException / Timeout | 프록시 엔드포인트가 느리거나, 응답이 없거나, 과부하이거나, 방화벽에 막힘; 기본 100초 타임아웃이 너무 짧음 | curl로 프록시 테스트; 엔드포인트가 실제로 동작하는지 먼저 확인한 뒤 HttpClient.Timeout 늘리기; 재시도 및 프록시 상태 점검 추가 |
| SocketException / Socket exhaustion | 요청마다 HttpClient나 핸들러를 생성·폐기함 | IHttpClientFactory, 싱글톤 클라이언트, 또는 풀링 제어가 있는 SocketsHttpHandler 사용 |
| SSL RemoteCertificateNameMismatch | 기업용 또는 관리형 프록시의 HTTPS 가로채기 | 필요한 경우 프록시 CA를 설치/신뢰; 통제된 개발 환경이나 승인된 MITM 시나리오에서만 사용자 지정 검증 사용 |
| 302 리디렉션 루프 | 기업 프록시/VPN의 캡티브 포털이나 허용 목록 차단이 반복 리디렉션을 유발 | 직접 연결로 테스트; Location 헤더 확인; 프록시 허용 목록 및 인증 포털 점검 |
| HttpRequestException / SOCKS URL에서 연결 불가 | .NET Framework나 구버전 .NET에서 SOCKS 코드를 실행함; 스킴 또는 포트가 틀림 | 기본 SOCKS 지원이 있는 .NET 6+ 사용; socks5://host:port 확인; 제공업체 문서로 테스트 |
| 프록시가 무시되는 것처럼 보임 | UseProxy = false; 대상이 로컬로 판단되어 우회됨; NO_PROXY 환경 변수; 핸들러가 예상과 다르게 구성됨 | UseProxy = true 설정; HttpClient.DefaultProxy 확인; 환경 변수 제거 또는 덮어쓰기; BypassProxyOnLocal = false 설정 |
빠른 디버깅 흐름
- 요청이 성공했는가? → 예:
api.ipify.org의 출력이 기대한 프록시 IP와 같은지 비교합니다. - 아니고 HTTP 상태 코드가 있는가? → 407: 프록시 자격 증명 수정. 403/429: 대상이 차단했거나 프록시에 속도 제한이 걸림. 3xx 루프: 프록시/기업 게이트웨이가 리디렉션 중일 수 있음.
- 상태 코드 없이 예외만 있는가? → 타임아웃: 프록시 도달 가능성 테스트. 소켓/인증서 예외: 풀링, 프로토콜, TLS, .NET 버전 확인.
.NET 밖에서 프록시 자체를 검증할 때 유용한 첫 명령어:
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# 코드만 안 된다면, 차이는 대개 인증 방식, TLS 신뢰 저장소, 환경 변수, 또는 자격 증명 이스케이프 문제입니다. curl의 프록시 URL, 스킴, 인증 방식을 정확히 맞춘 뒤 자격 증명만 NetworkCredential로 옮기세요.
프록시 관리를 건너뛰어도 될 때: 노코드 대안
“HttpClient proxy C#”을 검색하는 개발자 중 상당수는 프록시 이론을 배우려는 게 아니라, 스크래퍼를 계속 돌리려는 경우입니다. 이때는 직접 C# 프록시 코드를 짜는 것이 정말 필요한지, 아니면 아닌지 솔직하게 따져볼 가치가 있습니다.
다음과 같은 경우에는 프록시 회전을 포함한 커스텀 C# 스크래퍼를 만드세요:
- 요청 로직, 쿠키, 헤더, 재시도, 파싱을 완전히 제어해야 할 때
- 기존 .NET 코드베이스나 내부 서비스에 통합해야 할 때
- 컴플라이언스 또는 보안 요구사항 때문에 인프라를 끝까지 직접 책임져야 할 때
다음과 같은 경우에는 Thunderbit 같은 노코드 도구를 쓰세요:
- 목표가 HTTP 인프라가 아니라 웹사이트에서 구조화된 데이터를 추출하는 것일 때
- 프록시 풀 유지, CAPTCHA 처리, 소켓 고갈 디버깅을 직접 하고 싶지 않을 때
- 파싱 코드 없이 데이터를 Excel, Google Sheets, Airtable, Notion으로 바로 보내야 할 때
Thunderbit의 Chrome 확장 프로그램은 클라우드 스크래핑 옵션을 통해 프록시 회전과 봇 차단 대응을 자동으로 처리합니다. API를 사용하면 개발자가 JSON 스키마만 정의하고, HttpClient나 WebProxy를 직접 관리하지 않고도 구조화된 데이터를 받을 수 있습니다. 가격 비교를 위한 웹 스크래핑이나 리드 추출을 하는 팀이라면 설정 시간 차이가 매우 큽니다.
| 시나리오 | 커스텀 C# + 프록시 | Thunderbit |
|---|---|---|
| 요청 로직 완전 제어 | 예 | 아니오(API 수준 제어) |
| 프록시 관리 필요 | 예 | 아니오(자동 처리) |
| 봇 차단 / CAPTCHA 대응 | 수동 또는 외부 서비스 | 내장 |
| 설정 시간 | 수시간~수일 | 수분 |
| 가장 적합한 경우 | 기존 .NET 코드베이스, 맞춤 파이프라인 | 빠른 데이터 추출, 비기술 팀, 스프레드시트 내보내기 |
이건 “절대 HttpClient를 쓰지 마라”는 이야기가 아닙니다. 운영 중인 .NET 서비스를 만든다면 프록시 설정은 분명 이해해야 합니다. 하지만 일회성 데이터 수집 작업 때문에 407 오류를 잡느라 몇 시간을 쓰고 있다면, 더 단순한 선택지도 있습니다. 그런 방식을 써도 전혀 부끄러울 필요는 없습니다. Thunderbit의 요금제를 살펴보거나 YouTube 채널에서 데모를 확인해 보세요.
핵심 요약
핵심 패턴은 같습니다. WebProxy → 핸들러 → HttpClient. 그 이후는 운영 환경에서 드러나는 실수들을 피하는 문제입니다.
- 자격 증명은 핸들러가 아니라 프록시에 넣으세요. 407 섹션의 나란한 예시는 반드시 기억해야 할 가장 중요한 포인트입니다.
- 요청마다, 또는 프록시마다 새
HttpClient를 만들지 마세요. 이름 지정 클라이언트에는IHttpClientFactory, 회전형 게이트웨이에는PooledConnectionLifetime이 있는SocketsHttpHandler, 고급 시나리오에는 커스텀 라우팅 핸들러를 쓰세요. - SOCKS5나
SocketsHttpHandler코드를 복사하기 전에 .NET 버전을 확인하세요. 위의 호환성 표가 조용한 실패를 막아줍니다. - .NET 밖에서 먼저 프록시를 테스트하세요. 간단한
curl한 줄로 많은 디버깅을 줄일 수 있습니다. - 프록시 문제 없이 구조화된 데이터를 추출하고 싶다면, Thunderbit 같은 도구가 전송 계층을 대신 처리해 주므로 데이터 자체에 집중할 수 있습니다.
다음에 407이나 TaskCanceledException이 뜨면, 먼저 위의 문제 해결 표부터 확인하세요.
자주 묻는 질문
기존 HttpClient 인스턴스의 프록시를 바꿀 수 있나요?
아니요. 프록시는 핸들러에 묶여 있고, 핸들러는 생성 시점에 정해집니다. HttpClient에는 변경 가능한 Proxy 속성이 없습니다. 프록시가 다르면 별도의 핸들러와 클라이언트를 만들고, IHttpClientFactory의 이름 지정 클라이언트나 미리 구성된 클라이언트 풀로 관리하세요.
HttpClient는 기본적으로 시스템 프록시를 사용하나요?
예. 최신 .NET에서는 핸들러를 명시적으로 설정하지 않으면 HttpClient가 시스템 기본 프록시 설정을 따릅니다. 여기에는 HttpClient.DefaultProxy를 통해 HTTPS_PROXY, HTTP_PROXY 같은 환경 변수도 포함됩니다. 이를 사용하지 않으려면 핸들러에서 UseProxy = false를 명시하세요.
C#의 HttpClient에서 SOCKS5 프록시는 어떻게 사용하나요?
SocketsHttpHandler와 함께 new WebProxy("socks5://host:port")를 사용하세요. 기본 SOCKS 프록시 지원은 .NET 6 이상이 필요합니다. .NET Framework 4.x에서는 SOCKS5가 기본 지원되지 않으므로 서드파티 라이브러리가 필요합니다.
왜 계속 407 Proxy Authentication Required가 뜨나요?
대부분은 자격 증명을 handler.Credentials(대상 서버용)가 아니라 handler.Proxy.Credentials(프록시용)에 넣었기 때문입니다. 올바른 패턴은 위의 “프록시 자격 증명과 서버 자격 증명” 섹션을 참고하세요.
프록시를 사용할 때 SSL 인증서 검증을 꺼도 안전한가요?
로컬 개발 환경에서만, 또는 프록시 제공업체를 완전히 신뢰하는 경우에만 가능합니다(예: HTTPS 프록시 모드의 관리형 스크래핑 API). 표준 CONNECT 또는 SOCKS 프록시를 운영 환경에서 사용할 때는 중간자 공격을 막기 위해 SSL 검증을 켜 두세요.
손쉬운 웹 스크래핑을 위해 Thunderbit 사용해 보기 Get Started Free
더 알아보기
