프론트 프록시 뒤 원 클라이언트 IP 확보

[m-a-king]

왜

웹 트래픽이 프론트 리버스 프록시를 거쳐 우리 nginx 에 도착한다. client 의 next.config rewrites 가 /api/v1/* 전체를 프록시하므로, 브라우저와 앱 웹뷰에서 나가는 호출이 전부 여기를 탄다. 그 결과 nginx 가 보는 $binary_remote_addr 이 웹 사용자 전원에 대해 프록시 egress IP 하나다.

실측 (prod nginx 로그 14일, 2026-08-21):

• /api/ 요청 상위 IP 3개가 전부 프록시 egress (524건 · 421건 · 307건)
• 그 IP 들의 User-Agent 는 PIKI_APP, 카카오 인앱, 인스타 인앱 등 제각각이다. 서로 다른 실사용자가 한 IP 로 묶여 있다는 증거
• 프록시 IP 시간당 최대 59건 = 초당 0.016 (piki_general 한도의 0.1%), 14일간 429 는 0건

지금은 마진이 커 사고가 없지만, 요청 추적·이상 탐지·연결 계층 방어가 전부 실 IP 를 요구한다.

원 IP 는 이미 도착해 있다

프로브 3종으로 확인했다.

시나리오	앱이 받은 X-Forwarded-For
프록시 경유 + XFF 위조 시도	<실제 IP>, <프록시 IP> (위조값 폐기됨)
프록시 경유 (대조군)	<실제 IP>, <프록시 IP>
우리 API 직접 + XFF 위조	9.9.9.9, <실제 IP> (위조 성립)

프록시는 들어온 XFF 를 덮어쓰므로 프록시 경유분은 신뢰할 수 있다. 남은 문제는 하나뿐이다. "이 XFF 를 프록시가 보냈나, 공격자가 직접 보냈나."

참고로 X-Real-IP 로는 못 받는다. 우리 nginx 가 proxy_set_header X-Real-IP $remote_addr 로 덮어쓰기 때문에 프론트가 무엇을 보내든 지워진다.

무엇을

• 프론트가 공유 시크릿 헤더를 붙이고, nginx 는 그 헤더가 맞을 때만 XFF 를 키로 승격하는 map 을 둔다
• fail-safe: 헤더가 없거나 틀리면 현행 동작($binary_remote_addr)으로 떨어진다. 레이트리밋이 사라지지 않는다
• 시크릿은 SSM 보관 + 회전 경로를 둔다. 프론트에서는 서버 전용 env 여야 한다 (NEXT_PUBLIC_ 접두는 클라 번들에 박혀 공개된다)
• 용도를 분리한다. 관측·추적은 위조값 혼입을 감수하고 지금도 쓸 수 있다. 레이트리밋 키 승격은 위 신원 확인이 선행돼야 한다

검토 후 기각

대안	기각 사유
set_real_ip_from 으로 프록시 대역 화이트리스트	프록시 egress IP 가 고정이 아니다. 프로브 3회에서 매번 다른 IP 가 관측됐다. 고정 IP 는 상위 플랜 기능
프록시 제거 (브라우저가 API 를 직접 호출)	프론트 엣지 미들웨어가 페이지 네비게이션에서 refresh_token 쿠키를 읽어 transparent refresh 를 판단하는 구조다(TokenCookieWriter 주석, #512). 쿠키 도메인·CORS 를 포함한 세션 관리 재설계가 되어 비용 대비 편익이 성립하지 않는다

참고

• 계정별 한도로 대체된 nginx piki_llm zone 제거 #928 (조사 출처)