logo
GeekFormat

Forwarded Header 파서

표준 Forwarded 헤더

RFC 7239 Forwarded 프록시 체인을 분석하고 각 홉에서 for / by / host / proto 값을 확인합니다.

Hop #1
for203.0.113.43
protohttps
hostapp.geekformat.com
Hop #2
for10.0.0.9
byingress

X-Forwarded-* 호환 헤더

많은 게이트웨이 masih menggunakan X-Forwarded-For / Host / Proto. 이는 체인 순서로 클라이언트 및 프록시 주소를 분석합니다.

2개의 X-Forwarded-For 노드이 헤더는 신뢰할 수 있는 프록시 체인에서만 의미가 있으며 실제 클라이언트 IP로 처리되어서는 안 됩니다.
#1203.0.113.43
#210.0.0.9

JSON 미리보기

{
  "standardized": [
    {
      "index": 0,
      "pairs": {
        "for": "203.0.113.43",
        "proto": "https",
        "host": "app.geekformat.com"
      }
    },
    {
      "index": 1,
      "pairs": {
        "for": "10.0.0.9",
        "by": "ingress"
      }
    }
  ],
  "legacy": {
    "x-forwarded-for": [
      "203.0.113.43, 10.0.0.9"
    ],
    "x-forwarded-proto": [
      "https"
    ],
    "x-forwarded-host": [
      "app.geekformat.com"
    ]
  }
}

프록시 헤더를 온라인에서 분석하여 실제 출처와 전달 순서를 먼저 파악하세요.

관련 추천

사용 사례

  • 백엔드가 받은 클라이언트 IP가 올바르지 않을 때 Forwarded와 X-Forwarded-For를 먼저 분리하여 확인
  • 요청이 거친 CDN, Nginx, 게이트웨이 등 프록시 노드 순서 분석하여 전달 경로 확인
  • 리버스 프록시 설정 디버깅 시 Host와 Proto 투명 전송이 올바른지 확인하여 프로토콜 다운그레이드 방지
  • 다중 프록시 환경에서 요청 헤더가 변경되거나 손실된 원인 문제 해결 및 파싱 결과를 티켓에 복사

주요 기능

  • 다중 프록시 체인 직접 확인: 누가 누구에게 전달했는지, 프로토콜이 어떻게 변경되었는지 한눈에 파악
  • 실제 출처 더 안정적으로 파악: CDN, 게이트웨이, 리버스 프록시 및 다중 프록시 문제 해결에 적합
  • 게이트웨이 및 CDN 시나리오 친화적: Nginx, Ingress, 리버스 프록시, CDN 및 API 게이트웨이 문제 위치에 적합
  • 결과 구조화 표시: 필드별 상세 분석으로 티켓, 로그 분석 및 통합 테스트 기록에 복사하기 편리

이용 방법

  1. Forwarded 또는 X-Forwarded-For, X-Forwarded-Host, X-Forwarded-Proto 등 요청 헤더 내용을 붙여넣기
  2. 도구가 프록시 체인, 실제 IP, Host 및 Proto 필드를 자동으로 파싱하여 구조화하여 표시
  3. 프록시 노드 순서와 프로토콜 변환 정보를 확인하여 전달 경로가 예상과 일치하는지 확인
  4. 파싱 결과를 티켓, 로그 분석 또는 통합 테스트 기록에 복사

자주 묻는 질문

요청이 어떤 프록시 노드를 거쳤는지 어떻게 확인하나요?

관련 요청 헤더를 붙여넣으면 프록시 체인 순서와 각 홉이 전달한 정보를 확인할 수 있어 실제 IP 손실 또는 프로토콜 인식 오류 문제 해결에 특히 적합합니다.

왜 백엔드가 받은 클라이언트 IP가 올바르지 않나요?

일반적인 원인으로는 프록시 레이어가 투명 전송하지 않음, 게이트웨이가 요청 헤더를 덮어씀 또는 다중 CDN/리버스 프록시가 중첩된 경우가 있습니다. 이러한 헤더 정보를 파싱하면 IP가 어느 레이어에서 변경되었는지 판단할 수 있습니다.

Nginx, Ingress, API 게이트웨이 및 CDN 문제 해결에 적합한가요?

매우 적합합니다. 특히 원본 서버 요청 경로가 복잡하고 요청이 다중 프록시를 거칠 때 구조화된 헤더 정보 확인이 문제 해결 효율을 크게 향상시킵니다.

IP 외에 어떤 정보를 확인할 수 있나요?

출처 IP 외에도 Host, Proto, by 등 필드를 보조적으로 확인하여 프로토콜 변환, 도메인 투명 전송 및 프록시 동작이 예상과 일치하는지 확인할 수 있습니다.