403 에러 & Referrer vs Origin 차이점

403 Forbidden 은 서버가 요청을 이해했지만

“허용하지 않겠다”라고 명시적으로 거부할 때 발생하는 HTTP 상태 코드야.

 

즉,

“네가 뭘 요청하는지는 알겠는데, 이 권한으로는 접근 못 해.”

라는 뜻.

---

✅ 403 에러의 정확한 의미

• 요청 자체는 정상적임
• 서버는 요청의 형식·헤더·파라미터도 다 이해함
• 하지만 로그인/권한/정책/보안 규칙 등 때문에 접근을 허용하지 않음

그래서 서버가 일부러 ‘금지(Forbidden)’ 시키는 상황에서 발생함.

---

🔍 403이 일어날 수 있는 대표적인 경우

✔ 1) 인증은 되었지만 권한이 없음

예:

• 로그인은 했지만 관리자 페이지 접근
• 티켓팅 서버가 대기열을 통과한 사용자만 허용하는데 네가 통과하지 않음

✔ 2) IP / 기기 차단(보안 정책)

• 너무 많은 요청 → DDoS 의심
• VPN / 프록시 이용
• 해외 IP 차단
• 같은 PCID로 비정상적 접근 다수 발생

Q. VPN,프록시 차단 이유 / 같은 PCID로 비정상 접근?

✅ 1. VPN, 프록시를 왜 차단할까?

 

티켓팅·결제·로그인 같은 서비스는 VPN/프록시를 강하게 차단하는 편이야. 이유는 다음과 같아.

---

✔ 이유 1) 부정 예매·매크로·봇이 대부분 VPN을 사용

• 대량 예매를 시도하는 매크로들은 여러 IP 풀(VPN)로 계속 접속함
• 정상 사용자보다 VPN 이용률이 훨씬 높다
• 그래서 서버는 VPN IP를 블랙리스트/리스크 점수 기반으로 차단함

---

✔ 이유 2) IP를 수시로 바꾸며 요청을 보내기 때문

VPN은 요청할 때마다 IP가 바뀌기도 해.

 

예:

• PCID는 같아도
• IP는 계속 바뀜

그러면 서버 입장에서는:

“왜 같은 브라우저인데 IP가 1초마다 바뀌지?
→ 자동화 공격인가?”

라고 판단함.

---

✔ 이유 3) VPN에는 동일 IP를 수천 명이 공유하기 때문

일부 VPN 서버는 같은 IP를 수백~수천 명이 사용함.

 

그럼 서버는:

“한 IP에서 500명이 동시에 티켓팅을 시도한다?”
→ 100% 비정상 → 차단

이렇게 오판하는 게 아니라, 의도적으로 “리스크 높은 IP”로 분류해서 차단하는 것.

---

✔ 이유 4) 대기열/티켓팅 시스템(NetFunnel)이 IP 기반 검증을 사용

넷퍼널은 대기열 관리에 IP + 쿠키(PCID) 조합을 중요하게 봐.

하지만 VPN에서 IP가 바뀌면:

• 대기열 끊김
• 순번 초기화
• 부정 접근으로 인식 → 403

---

▶ 결론:

VPN은 보안상 위험한 환경으로 판단되기 때문에 서버가 차단하는 것이 매우 일반적임.

---

✅ 2. 같은 PCID로 접근하는데 비정상적일 수 있어?

✔ 가능함. 심지어 아주 흔함.

PCID는 “브라우저 식별자”일 뿐이고, IP 주소도 함께 본다.

 

서버는 보통 다음 조합으로 사용자 정상성을 판단함:

• PCID (기기)
• IP (네트워크 위치)
• NetFunnel_ID (대기열 상태)
• User-Agent (디바이스)

여기서 PCID와 IP가 함께 움직여야 자연스러움.

그러나 VPN을 쓰면 이런 상황이 생김:

요청	PCID	IP
1번째 요청	A	210.xxx.xxx.xxx
2번째 요청	A	185.xxx.xxx.xxx (VPN)
3번째 요청	A	43.xxx.xxx.xxx (VPN: 서버 변경)

 

서버 입장:

“기기는 같다고? 그런데 1초마다 IP가 다른 나라로 바뀜?”
→ 확실히 비정상 / 매크로 의심
→ 차단

그래서 PCID가 같아도 IP 변화가 비정상적이면 바로 차단함.

---

✅ 3. Referer(Referrer)과 Origin은 같은 거야?

❌ 둘은 완전히 다르다.

정확히 구분해야 해.

---

✔ Referrer (Referer)

“어떤 페이지에서 왔는가(출발지 URL)”

예:

https://example.com/page

→ 전체 URL이 담길 수 있음
→ path, query, fragment 모두 포함됨

---

✔ Origin

“요청을 보낸 출처(프로토콜 + 도메인 + 포트)”

 

예:

https://example.com

→ 오직 다음만 포함:

• scheme (https)
• host (example.com)
• port (443)

경로(path), 쿼리(query) 없음. 훨씬 단순함.

---

📌 둘의 차이 요약

항목	Referrer	Origin
의미	어떤 URL에서 왔는가	요청을 만든 출처
형식	전체 URL	scheme + domain + port
path 포함?	✔ Yeds	❌ No
CORS에서 사용?	드물게 사용	✔ 필수 사용
개인정보 위험성	높음	낮음

---

📌 예시로 비교

① Referrer

https://ticket.melon.com/performance/view.htm?prodId=12345

② Origin

https://ticket.melon.com

---

요약

① VPN/프록시 차단 이유

• 매크로/부정 접속이 대부분 VPN 사용
• IP가 계속 바뀜 → 비정상
• VPN IP는 여러 사용자가 공유 → 위험
• 티켓팅 시스템은 IP 기반 검증 필요

② 같은 PCID여도 비정상 가능

• PCID는 디바이스 식별
• IP는 네트워크 식별
• VPN 사용은 둘의 조합을 깨뜨림 → 비정상 패턴 판단

③ Referrer vs Origin

• Referrer: 전체 URL (출발지 페이지)
• Origin: 프로토콜+도메인 (출처)
• 둘은 서로 다르고 CORS는 주로 Origin 사용

---

원하면
“왜 티켓팅 사이트는 VPN을 극도로 싫어하는가?”
“티켓팅에서 정상으로 보이는 접속 패턴은 무엇인가?”
도 더 깊게 설명해줄 수 있어!

728x90

Q. 여러 IP 풀(VPN)으로 계속 접속한다

여기서 말하는 **“여러 IP 풀(VPN)로 계속 접속한다”**는 말은
매크로 프로그램이 ‘같은 사람/같은 컴퓨터’임을 숨기기 위해 IP 주소를 계속 바꿔가며 접속한다는 뜻이야.

 

조금 더 현실적인 상황으로 설명해줄게.

---

✅ 1. "대량 예매 매크로"가 하는 행동

티켓팅 매크로는 다음을 시도해:

• 예매 페이지에 초당 수십~수백 번 요청
• 로그인, 좌석 조회, 예매 버튼을 초고속 자동 클릭
• 사람보다 훨씬 빠른 속도로 서버를 두드림

이렇게 하면 서버가 당연히 의심함.

그래서 매크로 제작자들이 쓰는 꼼수:

---

✅ 2. 같은 컴퓨터라도 IP 주소를 계속 바꾸면 사람처럼 보일 수 있다고 생각함

매크로는 다음과 같은 VPN을 사용:

• 수백 개의 VPN IP 리스트(IP 풀)
• 또는 프록시 서버 수백 개
• 접속할 때마다 IP 교체(= rotating VPN)

즉,

한 대의 매크로 PC가 요청을 보낼 때마다
다른 나라/다른 지역/다른 회선의 IP처럼 보이도록 위장

 

예:

• 첫 번째 요청 → 미국 VPN IP
• 두 번째 요청 → 일본 VPN IP
• 세 번째 요청 → 한국 스타벅스 WiFi IP
• 네 번째 요청 → 독일 VPN IP

이렇게 계속 바꿔가며 서버를 속여서
“다른 사람이 접속하는 것처럼” 꾸미는 거야.

---

✅ 3. 그래서 서버는 "비정상적인 접근"으로 간주하고 차단함

왜냐하면 정상적인 유저라면:

• 1초마다 IP가 바뀌지 않음
• 클릭할 때마다 다른 국가 IP가 나오지 않음
• 로그인할 때마다 다른 IP면 정상 사용자가 아님

서버 입장에서는:

"이건 봇이 회피하려고 IP를 계속 갈아끼우는 패턴이네" → 차단

---

🔥 예시로 더 쉬운 설명

사람은 집에서 티켓팅하면:

192.168.0.xxx 로 고정적으로 나옴 (회선 IP 한 개)

 

하지만 매크로는:

1초째 → 112.211.x.x (한국 IP)
2초째 → 45.12.x.x (유럽 IP)
3초째 → 103.90.x.x (아시아 VPN)
4초째 → 8.8.x.x (미국 IP) ...

이런 식으로 “스팸 요청처럼” 보여 버림.

---

🧠 그래서 VPN을 쓰면 왜 차단될까?

1. 티켓 사이트는 VPN IP를 이미 블랙리스트로 알고 있음
2. VPN은 동일한 데이터센터 IP에서 수천 명이 접속함 → 비정상 트래픽
3. 여러 IP로 빠르게 변경되는 패턴은 매크로 특징
4. 같은 PCID·쿠키인데 IP만 계속 바뀌면 → “인간의 행동이 아님”

즉,

같은 PCID(쿠키)인데 IP가 계속 바뀌면 더더욱 매크로로 판단함.

 

그래서 VPN 사용자를 거의 다 차단하거나
문자 인증, 캡차 등을 강제로 거치게 함.

---

📌 한 줄 요약

매크로는 서버 감시를 피하려고 수백 개의 VPN·프록시 IP를 번갈아 쓰는데,
이런 패턴 자체가 “매크로의 전형적인 특징”이라서 오히려 차단 대상이다.

---

필요하면:

• “티켓 사이트가 매크로를 어떻게 잡는지(PCID, User-Agent, 쿠키, 브라우저 지문)”
• “VPN을 쓰면 왜 더 위험해지는지”
• “정상 사용자는 어떤 특징으로 판단되는지”

도 더 알려줄게!

---

 

Q. PCID

 

결론부터 딱 3줄로 핵심만 먼저 말할게:

PCID는 “기기 + 브라우저 조합” 단위로 고정되는 식별자다.

탭마다 바뀌지 않고, 브라우저를 바꾸면 달라지고, 기기를 바꾸면 달라진다.
브라우저 쿠키를 지우거나, 시크릿 모드면 새로 생성된다.

이제 자세히 설명해줄게.

---

✅ 1. PCID가 생기는 기준

PCID는 티켓팅 사이트들이 사용자 하나를 계속 식별하기 위해 쿠키에 넣는 고유값이야.
즉 이것이 없으면 서버는 "이 사람이 같은 사람인지" 판단하기 어렵지.

 

\PCID는 보통 이렇게 구분됨:

✔ ① 기기(device)가 바뀌면 PCID도 바뀜

• PC(컴퓨터) → PCID A
• 다른 PC → PCID B
• 휴대폰 → PCID C
• 태블릿 → PCID D
  각 장치는 독립적으로 PCID를 가짐.

즉, 브라우저가 쿠키를 저장하는 공간 자체가 기기마다 다르니까.

---

✔ ② 같은 기기라도 브라우저가 다르면 별개의 PCID

예:

기기	브라우저	PCID
Windows PC	Chrome	PCID A
Windows PC	Edge	PCID B
Windows PC	Firefox	PCID C

같은 컴퓨터에서 열어도
브라우저가 다르면 완전히 다른 PCID가 생김.

---

✔ ③ 같은 브라우저의 여러 탭? → PCID는 동일

탭은 단순히 브라우저의 같은 실행 환경일 뿐.

 

Chrome 탭 1 → PCID A
Chrome 탭 2 → PCID A
Chrome 새 창 → PCID A

즉 탭·새 창·창 여러 개 띄우기는 모두 동일 PCID를 공유함.

---

❗ 예외 상황 (이게 중요함)

✔ 쿠키 삭제하면? → 새로운 PCID 생성

PCID는 쿠키 기반이라,
쿠키를 지우면 서버는 “처음 방문한 사람”으로 인식함.

✔ 시크릿 모드(Incognito) → 매번 새로운 PCID

왜냐면 시크릿 모드는 종료하면 쿠키가 사라지기 때문.

✔ 프로필 분리(Chrome 사용자 전환) → PCID 다르게 부여됨

Chrome의 사용자(프로필)마다 쿠키 저장소가 다름.

---

🔥 정리표

상황	PCID 변화
탭 여러 개 열기	동일 PCID
새 창 열기	동일 PCID
같은 브라우저, 같은 기기	동일 PCID
다른 브라우저(Chrome → Edge)	다른 PCID
같은 브라우저라도 다른 기기	다른 PCID
쿠키 삭제	새로운 PCID
시크릿 모드	매번 새로운 PCID

---

💡 티켓팅 사이트는 왜 이렇게 PCID를 중요하게 보나?

• 매크로 탐지
• 과도한 요청 차단
• 같은 사람이 여러 계정 쓰는지 확인
• 비정상적인 IP 이동 감지
• VPN/프록시 악용 감지
• 특정 예매 횟수 제한

즉, PCID는 사실상 “사람 식별자” 역할임.

---

원하면
TKT_PCID / PC_PCID / NetFunnel_ID / TKT_POC_ID 이런 쿠키들 간의 관계
또는
PCID를 서버가 더 강하게 추적하는 방법(지문, UA 해시 등)
도 자세히 설명해줄게!

✔ 3) Referer / Origin 정책 위반

• 다른 도메인에서 불법적으로 호출할 때
• CORS 차단으로 인한 403 반환

✔ 4) User-Agent / 요청 헤더 문제

• 자동화 스크립트 감지
• 넷퍼널, 티켓팅 사이트는 봇 탐지에 실패하면 403을 바로 뱉어

✔ 5) 로그인 세션은 있지만 특정 쿠키가 없거나 비정상

특히 티켓팅 사이트:

• NetFunnel_ID 없으면 진입 차단
• TKT_POC_ID 유효하지 않으면 차단
• PCID 불일치 시 차단

---

❗ 403 vs 401(Unauthorized)

코드	의미
401 Unauthorized	“로그인 안 함 → 먼저 인증해라”
403 Forbidden	“인증했든 말든, 너는 접근 권한이 없다”

즉,
401은 로그인 필요,
403은 로그인해도 안 됨(권한 부족 또는 차단)

---

요약

403 Forbidden = 서버가 요청을 이해했지만 의도적으로 접근을 금지한 상황.
권한 부족, 정책 위반, 보안 차단, 쿠키/헤더 문제 등이 원인.

---

원하면 네가 겪은 403 상황에서
정확히 왜 발생했는지(쿠키/헤더/Origin/POC_ID/NetFunnel 관련)을 분석해줄게!

 

Q. Referrer vs Origin 차이

좋은 질문이고, 많은 개발자들이 처음에 헷갈리는 부분이기도 해.
결론부터 말하면:

❗ Referrer(레퍼러)와 Origin은 “표기법 차이”가 아니라 의미 자체가 완전히 다르다.

겉보기에 비슷해 보이지만 용도·보안·역할이 완전히 다름.

아래를 보면 왜 “엄연히 다른 개념인지”가 명확해질 거야.

---

✅ 1. 키 포인트 하나만 기억해도 됨

Referrer는 “사용자가 현재 보고 있던 페이지의 URL”

Origin은 “요청을 만든 출처(보안 경계선)”

 

즉,

• Referrer = “어떤 URL에서 이동/요청을 했는지 상세히 보고 싶다”
• Origin = “이 요청이 어느 '보안 도메인'에서 발생했는지 최소만 알려줘라”

보안 목적이 아예 다름.

---

📌 둘이 진짜 다르다는 걸 빠르게 보여주는 예시

✔ 예시 1 — HTTPS → HTTP 요청 시

브라우저는 Referrer는 보내지 않지만, Origin은 보낸다.

 

'왜?

• Referrer = 개인정보, query string, 식별 ID가 포함될 수 있음 → 유출되면 위험
• Origin = domain만 담음 → 경로/개인정보 없음 → 보내도 안전

즉,

Referrer는 개인정보 보호 때문에 브라우저가 마음대로 제거하기도 함.
Origin은 CORS 보안 판단 때문에 항상 필요.

만약 둘의 의미가 같다면 이런 차이가 있을 이유가 없음.

---

✔ 예시 2 — POST/PUT 같은 “위험한 요청”에서는 Origin만 강제됨

브라우저는 다음 요청에서 반드시 Origin을 보냄:

• POST
• PUT
• DELETE
• PATCH

왜냐면 CORS 보안 정책은 Origin을 기준으로만 판단하기 때문.

반면 Referrer는 브라우저가 보낼 수도, 안 보낼 수도 있음.

Referrer는 “추적용/로그용”
Origin은 “보안용”

용도가 다름.

---

✔ 예시 3 — Referrer는 아예 비워둘 수 있지만 Origin은 비울 수 없음

개발자가 이렇게 설정하면 Referrer는 전혀 안 보내짐:

<meta name="referrer" content="no-referrer">

하지만 이 설정을 해도 Origin은 계속 보내짐(보안 때문에).

 

즉,

Referrer는 “있으면 좋은 정보”
Origin은 “없으면 보안이 깨짐”

대체 가능한 정보가 아니다.

---

✔ 예시 4 — Referrer는 페이지 이동에도 따라다님. Origin은 API 요청에서만 사용됨.

Referrer는:

• 클릭해서 페이지 이동하면 → Referrer 포함됨
• 이미지, CSS, JS 불러와도 → Referrer 포함됨
• 링크 트래킹용

Origin은:

• AJAX, Fetch, XHR, 폼 제출 같은 요청에서만 사용됨
• 페이지 이동에는 사용되지도 않음

즉,

Referrer = 웹 분석 / 추적 / 로그
Origin = 보안 (CORS)

역할 자체가 겹치지 않음.

---

📌 결론: 의미가 다르다

같은 페이지에서 요청을 보내더라도 둘의 의미는 동등하지 않음.

✔ Referrer

“전 페이지의 정확한 URL은 이거다.”

→ 누가 어떤 페이지를 보고 있었는지 상세하게 알 수 있음
→ path / query / token / 검색어 / 상품 정보 / 사용자 ID 까지 포함될 수 있음
→ 개인정보/프라이버시 위험 존재

---

✔ Origin

“이 요청은 이 도메인에서 만들어졌다.”

→ scheme + domain + port
→ path, query 절대 포함 안 함
→ 프라이버시 보호됨
→ 보안(CORS)의 핵심

---

📌 요약표로 확실히 구분

항목	Referrer	Origin
의미	사용자가 직전에 보고 있던 전체 URL	요청을 생성한 보안 출처
보안 역할	없음(추적용, 로그용)	있음(CORS의 핵심)
개인정보 포함	YES (가능)	NO (절대 아님)
브라우저 정책	보내지 않을 수 있음	반드시 필요함
페이지 이동	Referrer 포함	Origin 불포함
API 요청	포함될 수도/안될 수도	반드시 포함됨

---

🔥 핵심 결론

Referrer는 “사용자가 어디서 왔는지 알려주는 정보”
Origin은 “브라우저가 보안을 위해 출처를 알려주는 정보”

 

둘은 겹치는 부분이 있을 뿐 의미가 절대 같지 않음.

---

원한다면
“Origin 스푸핑 가능?”,
“Referrer 없으면 CORS는 어떻게 동작?”,
“티켓팅 사이트에서는 Referrer와 Origin 중 무엇이 더 중요한가?”
같은 것들도 더 깊게 설명해줄게!

---

 

✅ 결론부터 말하면

HTML/JS/CSS/이미지 같은 "리소스 요청"에서는
Origin 헤더가 원칙적으로 아예 안 붙는다.

 

즉,

리소스 요청에는 Referrer는 있지만 Origin은 없다.
→ 그래서 Referrer = Origin 이 되는 경우는 없다.

이게 핵심이야.

---

🔍 왜 Origin이 없을까?

Origin 헤더는 원래 **"보안이 필요한 요청"**에서만 붙는다.

✔ Origin이 붙는 요청

• fetch()
• XHR / AJAX
• form submit (POST/PUT/PATCH/DELETE)
• WebSocket handshake
• 일부 cross-site 요청

✔ Origin이 붙지 않는 요청

• HTML 문서 다운로드
• CSS 다운로드
• JS 다운로드
• 이미지 다운로드
• 폰트 다운로드
• iframe 로드
• script/link/img 태그의 네트워크 요청

즉,

리소스 요청(resource request)에는 Origin이 기본적으로 없다.

 

---

💡 그래서 헷갈리던 "Referrer = Origin?" 상황은 왜 불가능한가?

네가 말한 것처럼:

“어떤 페이지에서 리소스를 요청했는데? 그럼 Referrer랑 Origin 둘 다 ticket.melon.com 아닌가?”

라고 생각할 수 있는데…

❗ 하지만 리소스 요청은 Origin 자체가 안 들어간다.

예시:

GET /image/banner.png HTTP/1.1
Host: ticket.melon.com
Referer: https://ticket.melon.com/page/view.htm?prodId=12345
Origin: 없음

 

즉,

Referrer는 있지만 Origin 헤더가 없으니까
“둘이 같은 값인지 비교하는 상황 자체가 발생하지 않는다.”

---

🔥 핵심 요약

요청 종류	Referrer	Origin
HTML/JS/CSS/이미지 같은 단순 리소스 요청	있음	없음
API 요청(fetch, AJAX, XHR)	있을 수도 있음	있음
폼 제출(POST 등)	있을 수도 있음	있음
페이지 이동	있음	없음

---

📌 그럼 언제 Referrer와 Origin이 동시에 존재하나?

오직 fetch/XHR/폼 제출 같은 요청에서만.

 

예:

POST /api/buy HTTP/1.1

Origin: https://ticket.melon.com
Referer: https://ticket.melon.com/performance/view.htm?prodId=12345

 

 

그리고 여기서도 절대로 같아지지 않아:

• Origin ⇒ https://ticket.melon.com
• Referer ⇒ https://ticket.melon.com/performance/view.htm?prodId=12345

즉, path/query가 있으니까 절대 같아지지 않음.

---

📌 결론 다시 딱 정리

Origin은 리소스 요청(이미지/JS/CSS)에는 안 들어간다.
→ 그래서 Referrer와 Origin이 “둘 다 존재하는 상황 자체”가 오직 fetch/XHR/폼 제출 요청뿐이다.

 

그리고 해당 상황에서도
Origin은 domain 수준
Referrer는 전체 URL
이라서 절대 같아질 수 없다.

---

원하면 내가 실제 브라우저 네트워크 패널로 찍은 예시나
티켓팅 사이트들의 Origin/Referrer 필터링 방식도 상세히 알려줄게!