<div id="readability-page-1" class="page"><div>
      
        <header>
          
          

  <p>
    

    

    
      
      

      <span>
        
        
          2 minute read
        
      </span>
    
  </p>


        </header>
      

      <section itemprop="text">
        
        <h2 id="l4-로드밸런서--nginx-환경에서-trailing-slash-리디렉션이-http-로-떨어지는-이슈와-해결법">L4 로드밸런서 + Nginx 환경에서 trailing slash 리디렉션이 HTTP 로 떨어지는 이슈와 해결법</h2>

<p><strong>요약</strong></p>

<p>L4 로드밸런서가 TLS를 종료하고 Nginx는 평문 HTTP로만 요청을 받는 구조에서,
<code>absolute_redirect off;</code> 한 줄로 HTTPS ↔ HTTP 섞임 + 404 문제를 깨끗이 잡았다.</p>

<p>핵심은 “<code>Location</code> 헤더가 상대 경로로 적혀있다면, 브라우저가 현재 스킴(HTTPS)을 계승하도록 RFC에 규정돼 있다”는 사실이다.</p>

<hr>

<h2 id="1-서비스-아키텍처">1. 서비스 아키텍처</h2>

<div><pre><code>Client (HTTPS)
      │
┌───────────────┐
│  L4  Load     │  ← TLS termination
│  Balancer     │
└───────────────┘
      │  (HTTP)
┌───────────────┐
│     Nginx     │  ← 평문 HTTP 수신
└───────────────┘
</code></pre></div>

<ul>
  <li><strong>TLS 검증</strong>: L4(Layer-4) 장비가 담당</li>
  <li><strong>Nginx</strong>: 80 포트에서만 평문 HTTP 를 수신</li>
  <li><strong>서비스 요구</strong>: <strong>모든 클라이언트는 반드시 HTTPS</strong> 로 접근해야 한다.</li>
</ul>

<hr>

<h2 id="2-재현-현상">2. 재현 현상</h2>

<ol>
  <li>사용자가 <code>https://domain/path</code>(뒤에 <code>/</code> 없음)을 요청</li>
  <li>Nginx 가 디렉터리로 간주 → 301 리디렉션 출력</li>
  <li><strong><code>Location: http://domain/path/</code></strong></li>
  <li>브라우저가 HTTP 로 재요청 → L4 는 TLS 없음 → 백엔드가 특정 리소스를 못 찾고 <strong>404</strong></li>
  <li>사용자는 “HTTPS 페이지가 왜 갑자기 깨져?” 당황</li>
</ol>

<hr>

<h2 id="3-원인-파헤치기">3. 원인 파헤치기</h2>

<h3 id="3-1-왜-http가-찍혔나">3-1. 왜 <code>http://</code>가 찍혔나?</h3>

<ul>
  <li>L4 → Nginx 구간은 <strong>평문 HTTP</strong></li>
  <li>Nginx 내부 변수 <code>$scheme</code> 값은 <strong>항상 <code>http</code></strong></li>
  <li><code>trailing slash</code> 자동 리디렉션 시 Nginx 는 절대 URL =<code>$scheme://$host/...</code> 로 만든다
→ 결과적으로 <strong><code>http://</code></strong> 가 박힘</li>
</ul>

<h3 id="3-2-404-까지-나오는-이유">3-2. 404 까지 나오는 이유</h3>

<ul>
  <li>우리 서비스는 HTTP 엔드포인트가 없음(혹은 WAF 차단)</li>
  <li>브라우저가 HTTP 로 다시 요청 → 404 또는 403</li>
</ul>

<hr>

<h2 id="4-해결책--한-줄-설정">4. 해결책 ― 한 줄 설정</h2>

<div><pre><code><span># nginx-vhosts.conf 또는 server 블록에</span>
<span>absolute_redirect</span> <span>off</span><span>;</span>
</code></pre></div>

<ul>
  <li>Nginx 가 리디렉션 <code>Location</code> 값을 <strong>상대 경로</strong>(<code>/pages/product-reg/</code>) 로만 내보내도록 강제</li>
  <li><code>$scheme</code> 등을 아예 쓰지 않으니 <strong>http/https 혼동 방지</strong></li>
</ul>

<hr>

<h2 id="5-왜-이게-먹히지--rfc-7231-때문">5. “왜 이게 먹히지?” — RFC 7231 때문</h2>

<blockquote>
  <p><strong>RFC 7231 §7.1.2 Location</strong>
“<code>Location</code> 값이 상대 URI 형식이면, 최종 값은 <strong>요청 URI effective request URI</strong> 를 기준으로 해석한다.”</p>
</blockquote>

<p>즉,</p>

<ul>
  <li>클라이언트(브라우저)가 상대 <code>Location</code> (<code>/path/</code>) 를 받으면
<strong>“내가 방금 보낸 URL 이 <code>https://…</code>였으니까, 거기에 그대로 붙이면 되겠군.”</strong></li>
  <li>그래서 HTTPS 스킴과 호스트를 <strong>클라이언트가 자동 계승</strong></li>
  <li>결과 리디렉션: <code>https://domain/path/</code></li>
  <li>curl로 테스트 해보아도 마찬가지</li>
</ul>

<hr>

<h2 id="6-변경-전후-패킷-흐름-요약">6. 변경 전후 패킷 흐름 요약</h2>

<table>
  <thead>
    <tr>
      <th>단계</th>
      <th>변경 전</th>
      <th>변경 후</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>클라이언트 → L4</td>
      <td>HTTPS</td>
      <td>HTTPS</td>
    </tr>
    <tr>
      <td>L4 → Nginx</td>
      <td>HTTP</td>
      <td>HTTP</td>
    </tr>
    <tr>
      <td>Nginx 301 응답</td>
      <td><code>Location: http://…</code></td>
      <td><code>Location: /…</code></td>
    </tr>
    <tr>
      <td>브라우저 재요청</td>
      <td>HTTP (↓ downgrade)</td>
      <td>HTTPS (스킴 계승)</td>
    </tr>
    <tr>
      <td>최종 응답</td>
      <td>404</td>
      <td>200</td>
    </tr>
  </tbody>
</table>

<hr>

<h2 id="7-실전-팁">7. 실전 팁</h2>

<ol>
  <li><strong>로컬/Dev 환경</strong>
    <ul>
      <li>HTTPS 가 없더라도 상대 <code>Location</code> 은 문제 없음</li>
    </ul>
  </li>
  <li><strong>다중 도메인</strong>
    <ul>
      <li><code>absolute_redirect off;</code> 는 호스트 별 인증서 교체 없이도 안전</li>
    </ul>
  </li>
</ol>

<hr>

<h2 id="8-마무리--한-줄-요약">8. 마무리 — 한 줄 요약</h2>

<p><strong>L4-TLS termination 환경에서 Nginx 의 <code>$scheme</code> 오판으로 생긴 HTTPS→HTTP 리디렉션은
<code>absolute_redirect off;</code> 로 상대 <code>Location</code> 헤더를 강제해 깔끔히 해결할 수 있다.</strong></p>

<p>표준(RFC 7231)이 이미 브라우저 쪽 “프로토콜·도메인 계승” 행동을 보장하니 안심하고 써도 된다.</p>

<hr>

<h3 id="참고-자료">참고 자료</h3>

<ul>
  <li><strong>RFC 7231</strong> – <a href="https://datatracker.ietf.org/doc/html/rfc7231#section-7.1.2">Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</a></li>
  <li><strong>RFC 3986</strong> – Uniform Resource Identifier (URI): Generic Syntax</li>
  <li>Nginx 문서 – <a href="https://nginx.org/en/docs/http/ngx_http_core_module.html#absolute_redirect"><code>absolute_redirect</code></a></li>
</ul>

<hr>

<p>EOD</p>

<p>20250604</p>

        
      </section>

      

      


      
  


    </div></div>

Never test

L4 로드밸런서 + Nginx 환경에서 trailing slash 리디렉션이 HTTP 로 떨어지는 이슈와 해결법
요약
L4 로드밸런서가 TLS를 종료하고 Nginx는 평문 HTTP로만 요청을 받는 구조에서,
absolute_redirect off; 한 줄로 HTTPS ↔ HTTP 섞임 + 404 문제를 깨끗이 잡았다.
핵심은 “Location 헤더가 상대 경로로 적혀있다면, 브라우저가 현재 스킴(HTTPS)을 계승하도록 RFC에 규정돼 있다”는 사실이다.
1. 서비스 아키텍처
Client (HTTPS)
      │
┌───────────────┐
│  L4  Load     │  ← TLS termination
│  Balancer     │
└───────────────┘
      │  (HTTP)
┌───────────────┐
│     Nginx     │  ← 평문 HTTP 수신
└───────────────┘
TLS 검증: L4(Layer-4) 장비가 담당
Nginx: 80 포트에서만 평문 HTTP 를 수신
서비스 요구: 모든 클라이언트는 반드시 HTTPS 로 접근해야 한다.
2. 재현 현상
사용자가 https://domain/path(뒤에 / 없음)을 요청
Nginx 가 디렉터리로 간주 → 301 리디렉션 출력
Location: http://domain/path/
브라우저가 HTTP 로 재요청 → L4 는 TLS 없음 → 백엔드가 특정 리소스를 못 찾고 404
사용자는 “HTTPS 페이지가 왜 갑자기 깨져?” 당황
3. 원인 파헤치기
3-1. 왜 http://가 찍혔나?
L4 → Nginx 구간은 평문 HTTP
Nginx 내부 변수 $scheme 값은 항상 http
trailing slash 자동 리디렉션 시 Nginx 는 절대 URL =$scheme://$host/... 로 만든다
→ 결과적으로 http:// 가 박힘
3-2. 404 까지 나오는 이유
우리 서비스는 HTTP 엔드포인트가 없음(혹은 WAF 차단)
브라우저가 HTTP 로 다시 요청 → 404 또는 403
4. 해결책 ― 한 줄 설정
# nginx-vhosts.conf 또는 server 블록에
absolute_redirect off;
Nginx 가 리디렉션 Location 값을 상대 경로(/pages/product-reg/) 로만 내보내도록 강제
$scheme 등을 아예 쓰지 않으니 http/https 혼동 방지
5. “왜 이게 먹히지?” — RFC 7231 때문
RFC 7231 §7.1.2 Location
“Location 값이 상대 URI 형식이면, 최종 값은 요청 URI effective request URI 를 기준으로 해석한다.”
즉,
클라이언트(브라우저)가 상대 Location (/path/) 를 받으면
“내가 방금 보낸 URL 이 https://…였으니까, 거기에 그대로 붙이면 되겠군.”
그래서 HTTPS 스킴과 호스트를 클라이언트가 자동 계승
결과 리디렉션: https://domain/path/
curl로 테스트 해보아도 마찬가지
6. 변경 전후 패킷 흐름 요약
단계
      변경 전
      변경 후
    
클라이언트 → L4
      HTTPS
      HTTPS
    
L4 → Nginx
      HTTP
      HTTP
    
Nginx 301 응답
      Location: http://…
      Location: /…
    
브라우저 재요청
      HTTP (↓ downgrade)
      HTTPS (스킴 계승)
    
최종 응답
      404
      200
    
7. 실전 팁
로컬/Dev 환경
    
HTTPS 가 없더라도 상대 Location 은 문제 없음
다중 도메인
    
absolute_redirect off; 는 호스트 별 인증서 교체 없이도 안전
8. 마무리 — 한 줄 요약
L4-TLS termination 환경에서 Nginx 의 $scheme 오판으로 생긴 HTTPS→HTTP 리디렉션은
absolute_redirect off; 로 상대 Location 헤더를 강제해 깔끔히 해결할 수 있다.
표준(RFC 7231)이 이미 브라우저 쪽 “프로토콜·도메인 계승” 행동을 보장하니 안심하고 써도 된다.
참고 자료
RFC 7231 – Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
RFC 3986 – Uniform Resource Identifier (URI): Generic Syntax
Nginx 문서 – absolute_redirect
EOD
20250604

L4 로드밸런서 + Nginx 환경에서 `trailing slash` 리디렉션이 HTTP 로 떨어지는 이슈와 해결법

댓글