[TroubleShooting] curl로는 재현되지 않는 CORS 에러, 원인은 서버가 아니라 브라우저였다 (with PNA)

📍 curl로는 재현되지 않는 CORS 에러, 원인은 서버가 아니라 브라우저였다 (with PNA)

📝 TL;DR

• T&A dev 환경에서 특정 API 호출 시 CORS 에러로 실패했다.
• 원인은 일반적인 CORS 문제가 아니라 Chrome의 Private Network Access(PNA) 정책이었다.
• dev 환경의 API 도메인은 내부 IP로 resolve 되는 반면, 호출하는 페이지는 public 사이트라서 브라우저가 "이 사이트가 로컬 네트워크 기기에 접근하려 합니다"라며 권한 확인을 요구했고, 그 권한이 허용되지 않은 상태라 요청이 막혔다.
• 운영 환경은 API 도메인이 public IP(CDN)로 나가기 때문에 이 문제가 발생하지 않는다 — 내부망을 직접 노출한 dev 환경 고유의 이슈였다.

증상

카테고리 클릭하면 아래 엔드포인트를 fetch 한다.

GET https://api.dev.example.in/category-overview

 

이미 같은 코드로 잘 동작하던 다른 dev 호스트(dev-example.com)에서는 문제가 없었는데, 새로 붙인 dev-tour.example.com에서만 브라우저 콘솔에 다음 에러가 떴다.

Access to fetch at 'https://api.dev.example.in/category-overview'
from origin 'https://dev-tour.example.com' has been blocked by CORS policy:
Permission was denied for this request to access the `local` address space.

 

Network 탭에서는 실제 요청이 나간 흔적 없이 Response headers (0), (provisional headers are shown) 상태로 표시됐다. 이를 통해 preflight 단계에서 막힌 상태임을 짐작할 수 있었다.

처음 의심한 것들

1. host 화이트리스트 미등록?
   curl로 각각 Origin/헤더를 포함하여 요청하니 서버는 200을 반환했고, Access-Control-Allow-Origin에 요청한 origin이 응답했다. 이로써 화이트리스트 문제는 아니라는 것을 판단했다.
2. 커스텀 헤더 문제?
   Access-Control-Request-Headers에 커스텀 헤더 2개를 명시해서 preflight를 보내봐도 서버는 정상적으로 허용 응답을 줬다.
3. 서버 설정 차이?
   두 origin으로 완전히 동일한 preflight를 보내 비교했지만 서버 응답은 다르지 않았다. 서버 쪽 설정 차이는 아니었다.

curl로는 아무리 재현해도 문제가 나타나지 않았는데 이건 애초에 서버 응답이 아니라 브라우저 자체의 정책이었기 때문이다. curl은 CORS를 강제하지 않는 도구라 이 계층의 문제를 재현할 수 없었다.

원인 — Private Network Access (PNA)

몇 번의 삽질 끝에, 처음으로 돌아가 브라우저 콘솔 에러 메시지를 자세히 다시 읽어봤다.

> Permission was denied for this request to access the 'local' address space.

 

이건 일반적인 CORS 에러 메시지가 아니었다. Chrome은 몇 년 전부터 public 웹사이트가 사설/로컬 네트워크 주소로 요청을 보내는 것에 대해 별도의 보안 계층을 적용하고 있다. 이를 Private Network Access(PNA)라 부른다.

 

쉽게 말해, 공개 인터넷에 있는 아무 웹사이트나 방문했을 때 그 사이트가 스크립트로 여러분의 공유기 관리 페이지(192.168.x.x)나 사내 서버(10.x.x.x)에 접근할 수 있다면 위험하다. 그래서 브라우저는 이런 요청에 별도의 승인 절차를 요구한다.

 

실제로 요청하는 API 호스트의 IP는 다음과 같았다.

$ dig +short api.dev.example.in
...dev.example.in.
10.0.xx.xx
10.0.xx.xx
...

 

즉, 사설 IP(10.0.x.x)로 resolve된다. 반면 dev-tour.example.com은 CDN의 public IP에서 서빙됨을 확인했다.

$ dig +short dev-tour.example.com
cloudflare...
172.xx.x.xxx
162.xxx.xxx.xxx

브라우저는 주소 공간을 3단계로 나눈다

PNA가 보는 건 "사설 IP냐 아니냐"라는 이분법이 아니다. Chrome은 주소 공간을 public < private < local 3단계로 나누고, 요청을 보내는 페이지보다 대상이 더 폐쇄적인 단계로 갈 때만 체크를 건다.

• public — 인터넷 어디서나 도달 가능한 주소 (CDN, 공개 서버 등)
• private — 사설 IP 대역(10.x.x.x, 172.16~31.x.x, 192.168.x.x)에 속하는 주소
• local — localhost, 127.0.0.1 등 그보다 더 좁은 범위

이번 케이스는:

• 요청을 보낸 페이지(dev-tour.example.com) → CDN의 public IP → public 단계
• 요청 대상 API(api.dev.example.in) → 사내 클러스터 사설 IP → private 단계

public → private로 가는 요청이라 정확히 체크 대상에 들어맞았다. 만약 요청을 보낸 페이지도 사내망 IP에서 서빙되고 있었다면(private → private), 요청자와 대상의 폐쇄도가 같으니 이 체크는 처음부터 발동하지 않았을 것이고, PNA 이슈도 없었을 것이다.

브라우저가 "물어보고" 서버가 "답해야" 통과한다

이 판단은 preflight 요청/응답의 특정 헤더 한 쌍으로 오간다. 이름이 비슷해서 헷갈리기 쉬운데, 질문과 답변이 서로 다른 헤더다.

1. 브라우저 → 서버 (OPTIONS preflight)
   Access-Control-Request-Private-Network: true

2. 서버 → 브라우저 (preflight 응답)
   Access-Control-Allow-Private-Network: true

3. 브라우저: Access-Control-Allow-Private-Network 응답을 받으면 안전하다고 판단하고 그제서야 진짜 GET 요청을 보낸다

 

이번 이슈에서 실제로 벌어진 일은, 브라우저가 Access-Control-Request-Private-Network 헤더는 정상적으로 보냈지만 응답에는 Access-Control-Allow-Private-Network 헤더가 없었던 것이다. 서버에서 응답 헤더가 내려오지않았고, 이로인해 브라우저가 요청을 막은 것으로 보였다.

왜 다른 서비스는 문제없이 되고 있었나

가장 헷갈렸던 부분이다. 같은 코드, 같은 API를 호출하는 dev-example.com은 잘 되고 있었기 때문에, 처음엔 "서버가 origin별로 다르게 취급하나?"라는 잘못된 가설을 세웠다. 하지만 서버 응답을 아무리 비교해도 차이가 없었다.

 

실제 원인은 브라우저 쪽에 있었다. Chrome의 PNA는 사이트별 최초 요청 시 사용자에게 권한을 확인하는 팝업을 띄우고, 사용자가 승인하면 그 결정이 브라우저에 남는다. dev-example.com을 오래 써온 개발자의 브라우저에는 이미 이 권한이 허용된 상태로 남아 있었을 뿐, 서버가 그 origin을 특별 취급한 게 아니었다.

 

이걸 확인하기 위해 Chrome 설정에서 해당 사이트의 "로컬 네트워크" 권한을 허용으로 바꾼 뒤 재시도했더니 dev-tour.example.com에서도 정상적으로 API가 호출됐다. 이걸로 원인이 PNA인 것으로 판단했다.

왜 운영(prod) 환경은 이 문제가 없을까?

운영 환경의 API 도메인을 확인해보면 dev와 다르다.

$ dig +short api.example.com
cdn-edge.example.com.
203.0.xxx.xx
203.0.xxx.xx

운영 API는 CDN을 통해 public IP로 노출된다. 즉 운영 트래픽은 "public → public" 요청이라 PNA 체크 조건 자체가 성립하지 않는다. dev 환경에서만 BFF가 내부망 IP로 직접 노출되어 있었기 때문에 생긴, dev 환경 고유의 문제였다.

해결 방향

환경별로 요청/대상의 주소 공간 조합이 다르기 때문에, 필요한 조치도 환경별로 다르다.

• dev (내부망 환경): API가 사설 IP로 노출돼 있어 public → private 조합이 발생한다. 이 환경은 사내 인원만 접근하는 개발 환경이므로 브라우저의 로컬 네트워크 접근 권한을 허용해두는 방식으로 정리했다.

• 운영(prod): API가 CDN을 통해 public IP로 노출돼 있어 public → public 요청이다. PNA 체크 조건 자체가 성립하지 않으므로 별도 조치가 필요 없다.

정리

• 증상: dev 환경의 특정 신규 호스트에서만 발생한 CORS 에러로 API 호출 실패
• 원인: 브라우저의 Private Network Access(PNA) — public 사이트에서 사설 IP로 노출된 dev API를 호출할 때 발생
• 헷갈렸던 이유: 브라우저 정책이라 서버 쪽(curl, 응답 헤더 비교)으로는 재현/판별이 안 됐고, 다른 호스트에서 "잘 되고 있었다"는 것도 서버 설정이 아니라 그 브라우저에 남아있던 과거 권한 승인 상태였다
• 해결: dev/qa는 내부망 환경이므로 브라우저의 로컬 네트워크 접근 권한을 허용, 운영 환경은 API가 public IP로 노출되어 있어 원천적으로 이 문제가 발생하지 않아 별도 조치 불필요

참고

• Private Network Access: introducing preflights (Chrome for Developers)
• Private Network Access (W3C Draft)