이 글의 목적은 웹 브라우징이나 API 호출 중 발생하는 HTTP 403 Forbidden과 429 Too Many Requests 에러의 원인과 진단·해결 절차를 체계적으로 정리하여 현장에서 즉시 적용할 수 있도록 돕는 것이다.
1. HTTP 403·429의 의미와 차이 이해
HTTP 403은 서버가 요청을 이해했지만 권한 또는 정책 위반으로 리소스 제공을 거부함을 의미한다.
HTTP 429는 단위 시간 내 허용량을 초과했음을 뜻하며, 서버나 게이트웨이, CDN, WAF가 속도 제한 정책에 의해 요청을 일시적으로 차단했음을 나타낸다.
두 상태 코드는 모두 의도적으로 접근을 제한하는 응답이라는 공통점을 가지며, 단순한 통신 오류가 아니므로 요청 재시도만으로 해결되지 않는 경우가 많다.
핵심: 403은 권한·정책 문제, 429는 요청 빈도 문제로 구분하여 진단한다.
2. 빠른 체크리스트: 증상별 1차 조치
| 증상 | 가능 원인 | 즉시 조치 |
|---|---|---|
| 403 Forbidden 반복 | 세션 쿠키 손상, 권한 부족, 국가·IP 차단, 리퍼러·User-Agent 정책 | 쿠키·사이트 데이터 초기화, 로그인 재확인, VPN·프록시 해제, 브라우저 시크릿 모드 재시도 |
| 429 Too Many Requests | 요청 속도 초과, 봇 탐지, 동일 IP 과다 트래픽 | 요청 간격 늘리기, 지수적 백오프 적용, HTTP 429의 Retry-After 헤더 준수 |
| 특정 경로만 403 | 디렉터리·파일 권한 정책, WAF 룰, 핫링크·리퍼러 차단 | 다른 경로 비교, 헤더 최소화, 리퍼러 비우고 테스트 |
| 로그인 페이지만 403 | CSRF 토큰 누락, 세션 만료 | 전체 쿠키 삭제 후 재로그인, 새 창에서 재접속 |
| API 호출만 429 | API 키 공유, 미들웨어 레이트 리밋 | 요청당 토큰·엔드포인트별 쿼터 확인, 호출 배치·캐싱 |
3. 진단 절차: 클라이언트부터 서버까지
3.1 브라우저·클라이언트 측 점검
- 사이트별 데이터 제거를 수행한다. 주소창 자물쇠 아이콘 클릭 후 쿠키·사이트 데이터 삭제를 진행한다.
- 브라우저 확장 프로그램을 모두 비활성화하고 시크릿 모드로 재시도한다.
- VPN·프록시·기업용 보안 우회 터널을 해제하고 ISP 기본 경로로 접속한다.
- 시간 동기화를 확인한다. 시스템 시간이 크게 어긋나면 인증·서명 검증 실패로 차단될 수 있다.
- 로그인 상태를 재확인한다. 세션 만료·토큰 누락은 CSRF 검증 실패로 403을 유발할 수 있다.
3.2 요청 헤더·빈도 분석
불필요한 헤더나 자동화 흔적은 차단을 유발할 수 있다. 최소 헤더로 재현 테스트를 수행한다.
curl -i https://example.com/protected \
-H "User-Agent: Mozilla/5.0" \
-H "Accept: text/html,application/xhtml+xml"
429 응답의 Retry-After 헤더를 확인하여 재시도 대기 시간을 준수한다.
HTTP/1.1 429 Too Many Requests
Retry-After: 60
429가 지속되면 클라이언트 측에서 지수적 백오프를 적용한다.
// 의사코드
delay = base
while (429) { sleep(delay); delay = min(delay*2, maxDelay) }
3.3 네트워크·IP 레벨 점검
- NAT 환경에서 다수 단말이 동일 공인 IP로 나가면 한 IP에 대한 레이트 리밋에 걸릴 수 있다. 필요시 회선 분리 또는 IP 풀을 사용한다.
- 기업 프록시·SSL 검사 장비가 트래픽을 재가공하면 특정 헤더·서명 검증이 실패할 수 있다. 우회 예외 정책을 검토한다.
3.4 서버·CDN·WAF 정책 점검
서버 또는 앞단의 CDN·WAF 정책이 원인일 수 있다. 운영자 관점에서는 다음 항목을 확인한다.
- 접근 제어 목록(ACL)·국가 차단·AS 차단
- 봇 관리 정책과 시그니처 기반 차단
- 리퍼러·Hotlink 방지 설정
- 레이트 리밋 임계치, 버스트 허용량, 윈도우 크기
- 정상 사용자 식별을 위한 쿠키·토큰 발급 절차
4. 원인별 상세 해결책
4.1 쿠키·세션 문제
세션 식별 쿠키가 손상되거나 만료되면 인증이 통과되지 않아 403이 발생한다. 사이트별 쿠키와 로컬 스토리지를 삭제하고 새 로그인 흐름을 수행한다. SSO 환경에서는 브라우저 간 혼합 로그인이 토큰 충돌을 일으킬 수 있으므로 동일 브라우저로 일관되게 접근한다.
4.2 VPN·프록시·클라우드 회선
공용 VPN IP 또는 데이터센터 대역은 봇 트래픽으로 분류되어 차단될 가능성이 높다. 기업 프록시의 헤더 삽입으로 정책 위반이 발생할 수도 있다. 가장 단순한 경로로 재시도하고, 필요시 프록시 예외 목록에 도메인을 추가한다.
4.3 봇 탐지와 자동화 스크립트
비정상적인 User-Agent, 헤더 순서, 쿠키 미사용, 자바스크립트 비활성화, 헤드리스 브라우저 지표는 차단 트리거가 될 수 있다. 자동화가 필요하다면 정식 API를 사용하고, 인간 브라우저 환경을 흉내 내려 하지 않는다.
4.4 리퍼러·핫링크·오리진 정책
이미지·정적 파일을 외부 도메인에서 임베드하면 리퍼러 기반 차단으로 403이 발생할 수 있다. 동일 출처 정책을 준수하고, 필요한 경우 서버에서 CORS 및 핫링크 허용 도메인을 명시한다.
4.5 권한·소유권·디렉터리 설정
서버 측 권한 오류로 인해 403이 발생할 수 있다. 웹 서버 계정의 읽기 권한, 인덱스 파일 유무, 디렉터리 리스팅 정책을 점검한다.
# Apache 기본 예시
<Directory "/var/www/html/private">
Require valid-user
Options -Indexes
</Directory>
# Nginx 예시
location /private/ {
deny all;
}
4.6 레이트 리밋과 429 대응
429는 시스템 보호를 위한 정상 동작이다. 클라이언트는 다음 원칙을 따른다.
- Retry-After를 우선 준수한다.
- 지수적 백오프와 Jitter를 적용하여 동시 재시도를 분산한다.
- 캐싱·중복 제거·배치 처리로 호출 수를 줄인다.
- 엔드포인트당 쿼터를 분리하고 키를 공유하지 않는다.
5. 개발자·운영자 체크리스트
5.1 서버·WAF 구성 베스트 프랙티스
| 항목 | 권장 설정 | 비고 |
|---|---|---|
| 429 응답 | Retry-After 헤더 포함 | 초 단위 또는 HTTP 날짜 |
| 레이트 리밋 | 토큰 버킷·슬라이딩 윈도우 병행 | 버스트 처리와 공정성 확보 |
| 403 정책 | 정규화된 차단 사유 코드·로그 남김 | 운영자 디버깅 단축 |
| 봇 관리 | 허용 리스트에 합법적 크롤러 등록 | UA·Reverse DNS 검증 |
| IP 차단 | 동적 평판 기반, 자동 해제 타이머 | 영구 차단 최소화 |
5.2 Nginx 레이트 리밋 예시
# IP 기반 레이트 리밋
limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;
server {
location /api/ {
limit_req zone=perip burst=20 nodelay;
add_header Retry-After 1 always;
}
} 5.3 Apache 레이트 리밋 예시
# mod_ratelimit, mod_evasive 활용 예시 스니펫
DOSHashTableSize 3097
DOSPageCount 20
DOSPageInterval 1
DOSBlockingPeriod 60
5.4 API 서버에서의 응답 설계
- 429에는
Retry-After외에X-RateLimit-Limit,X-RateLimit-Remaining,X-RateLimit-Reset같은 관측 지표를 통일된 형식으로 포함한다. - 403에는 세부 사유 코드를 바디에 JSON으로 제공한다. 예:
{"code":"GEO_BLOCKED","message":"region blocked"}
6. 보안 정책과 합법적 접근
403·429를 우회하려는 시도는 서비스 약관·법령 위반이 될 수 있다. 자동화가 필요하면 공식 API와 인증 절차를 사용하고, 데이터 수집은 명시적 허용 범위에서 수행한다. 관리자는 개인정보·계정 보호를 위해 의심 트래픽을 선제 차단할 의무가 있다.
7. 운영 환경에서의 관측·모니터링
| 지표 | 목적 | 경보 기준 |
|---|---|---|
| HTTP 403 비율 | 권한·정책 오탑재 감지 | 평시 대비 2배↑ 5분 지속 |
| HTTP 429 비율 | 레이트 리밋 임계치 타이트 여부 | 특정 엔드포인트 5%↑ |
| 유니크 IP 수 | 봇·공격·플래시 크라우드 구분 | 평균+3σ 초과 |
| Retry-After 평균 | 대기 시간 체감 관리 | 60초 초과 시 재조정 |
8. 현장에서 자주 묻는 문제와 해법
8.1 기업망에서 특정 사이트만 403
SSL 검사 장비가 중간자 역할을 하며 인증서 재서명으로 트래픽을 변경했을 수 있다. 예외 도메인으로 등록하거나 해당 구간을 바이패스한다.
8.2 이미지 임베드만 403
핫링크 방지가 작동한 것이다. 동일 스키마·도메인으로 제공하거나 이미지 프록시를 자체 서버에서 제공한다.
8.3 API 크론 잡이 일정 시간대에 429
동일 시각에 다수 잡이 몰리기 때문이다. 시작 시간을 랜덤 지연시켜 분산하고, 캐시를 도입한다.
9. 현장 적용 스텝바이스텝
- 에러 캡처:
status, url, method, headers, response headers를 기록한다. - 분류: 403이면 권한·정책 축, 429이면 빈도·할당량 축으로 나눠 원인을 좁힌다.
- 클라이언트 조치: 쿠키 초기화, 로그인 재확인, 확장 비활성화, VPN·프록시 해제 후 재시도한다.
- 요청 조정: 헤더 최소화, 백오프 적용, 캐시 도입, 배치·큐잉으로 호출을 줄인다.
- 서버 협의: 필요시 운영자에게 차단 사유 코드·로그를 요청하고 화이트리스트 또는 정책 완화 가능성을 검토한다.
10. 디버깅 명령어 예시 모음
# 1) 최소 헤더로 재현
curl -I "https://target.example/resource" -H "User-Agent: Mozilla/5.0"
# 2) 세션 유지 시도와 비교
curl -I -c cookies.txt -b cookies.txt "[https://target.example/me](https://target.example/me)"
# 3) 429 응답 헤더 확인
curl -i "[https://api.example/v1/data](https://api.example/v1/data)" | sed -n '1,20p'
# 4) 리퍼러 제거 테스트
curl -I "[https://static.example/img.png](https://static.example/img.png)" -H "Referer:"
# 5) 지수 백오프 의사코드 파이프라인
# while status==429; sleep(t); t=min(t*2, 60)
11. 정책 설계 체크포인트
- 사전 공지: 개발자 문서에 한도와 갱신 주기를 명시한다.
- 투명 응답: 429에는 쿼터 정보, 403에는 사유 코드를 포함한다.
- 예외 경로: 결제·인증 등 핵심 흐름은 더 완만한 리밋을 적용한다.
- 관용 구간: 신규 릴리스·이벤트 기간에는 임시 상향한다.
- 자동 해제: 일시적 과다 트래픽은 일정 시간 뒤 자동 해제한다.
12. 체크리스트 템플릿
| 구분 | 점검 항목 | 상태 | 비고 |
|---|---|---|---|
| 클라이언트 | 쿠키·캐시 초기화, 로그인 재확인 | □ | |
| 네트워크 | VPN·프록시 해제, 기업 SSL 검사 예외 | □ | |
| 요청 | 헤더 최소화, 백오프 적용, Retry-After 준수 | □ | |
| 서버 | WAF·레이트 리밋 로그 확인, 사유 코드 제공 | □ |
FAQ
브라우저에서만 403이 발생하고 curl은 정상 동작한다면 무엇을 보아야 하나?
브라우저 확장, 리퍼러, 크로스사이트 쿠키, CORS 사전 요청이 원인일 수 있다. 시크릿 모드에서 확장 비활성화 후 재시도하고, 요청 헤더 차이를 비교한다.
Retry-After가 없는 429는 어떻게 다루어야 하나?
클라이언트에서 기본 백오프 전략을 적용한다. 예를 들어 1초에서 시작하여 2배씩 증가시키고 상한을 둔다. 동시 재시도를 분산하기 위해 지터를 추가한다.
정상 사용자도 차단되는 오탐이 반복된다면?
IP 평판·국가 차단·봇 관리 오탐 가능성이 있다. 운영자에게 시간대·요청 ID를 제공하고 화이트리스트 또는 룰 완화를 요청한다.
같은 공인 IP를 쓰는 사내에서만 429가 뜬다.
NAT 뒤 단말 수가 많아 IP당 요청량이 누적되기 때문이다. 호출을 분산하거나 게이트웨이에서 IP 풀 사용을 검토한다.
이미지·CSS가 403인데 HTML은 정상이다.
핫링크 방지 또는 경로별 권한 정책 때문이다. 동일 출처로 제공하거나 정적 자산 도메인에 대한 리퍼러 허용 목록을 설정한다.