---
title: HTTPS_PROXY 통신 흐름 실측 가이드 — CONNECT 이후 · 연결 재사용 · 재현 랩
date: 2026-07-17
type: guide
domain: networking
tags: [squid, forward-proxy, http-connect, https-proxy, connection-reuse, keep-alive, http2, tls, lab]
---


> [!note] 원본은 스타일링된 HTML 실측 가이드
> 이 글의 본체는 실측 가이드 전문이다. raw socket + `ssl.MemoryBIO`로 찍은 와이어 바이트, 5케이스 재사용 매트릭스, 재현 랩 전체 스크립트, 랩에서 밟은 함정 6개를 포함한다. 모든 수치는 Squid 6.14 · curl 8.5 · TLS 1.3 랩 실측값.
>
> **[→ 전문 보기 (https-proxy-connect-flow-and-lab.html)](files/https-proxy-connect-flow-and-lab.html)**
>
> 이 페이지는 핵심 요약본.

## 한 문단 요약

CONNECT 200 이후에도 새로 열리는 것은 없다. 프록시에 연결했던 같은 소켓(fd) 위에서 앱↔프록시의 평문 대화(전반)와 앱↔origin의 암호화 대화(후반)가 시간순으로 이어질 뿐이고, Squid는 후반부에서 화자가 아니라 전선이다. "연결 재사용"이 헷갈리는 이유는 연결이라는 한 단어가 네 개 층(TCP·터널·TLS 세션·HTTP 요청)을 가리키기 때문 — 위 세 층은 한 몸으로 태어나 함께 죽고, 요청만 N개다. 그래서 터널 수를 정하는 주체는 Squid가 아니라 앱과 origin이다. keep-alive면 3요청이 1터널, `Connection: close`면 요청마다 새 터널·새 ACL 심사·새 로그 줄, HTTP/1.1 동시 요청은 반드시 터널을 늘리고 HTTP/2는 스트림으로 접어 넣는다. 이 성질이 egress gateway(A안) 용량 산정의 기준 단위가 "요청 수"가 아니라 "동시 터널 수"인 이유다.

## 구성

| 장 | 주제 | 핵심 |
|---|---|---|
| 00 | 세 줄 요약 | 소켓 하나·대화 둘, TLS 세션 단위, 터널 수는 앱이 정한다 |
| 01 | CONNECT 이후 | 같은 fd 위에서 화자만 바뀐다. ACL 심사는 터널 개설 시 딱 1회 |
| 02 | 바이트로 확인 | raw socket 실측 — SNI만 평문, 경로 문자열은 와이어에서 소멸 |
| 03 | 연결 재사용과 네 개의 층 | TCP·터널·TLS는 1개, 요청만 N개. 풀 키 = (scheme, host, port, proxy) |
| 04 | 재사용 매트릭스 | 5케이스 실측 — 측정 원리는 "터널 1개 = access.log 1줄" |
| 05 | 재현 랩 구성 | 세 관측 지점(앱·Squid·origin) + 가짜 프록시·MemoryBIO 트릭 |
| 06 | 함정 6개 | ACL first-match, ipcache, 단일 스레드 교착, 404=close 등 |
| 07 | 진단 치트시트 | 파드에서 읽기 전용으로 실패 구간 판별 |

## 재사용 매트릭스 — 5케이스 실측

| 케이스 | 조건 | 요청 | 터널 |
|---|---|---|---|
| A | 순차 · keep-alive · 같은 호스트 | 3 | **1** |
| B | 순차 · `Connection: close` | 3 | 3 |
| C | 병렬 · HTTP/1.1 | 3 | 3 |
| D | 순차 · 서로 다른 호스트 | 2 | 2 |
| E | 병렬 · HTTP/2 | 3 | **1** |

## 운영에서 놓치기 쉬운 것

1. **Squid 로그 줄 수는 요청 수가 아니라 터널 수다.** keep-alive면 3요청이 1줄, h2 앱이면 수천 요청이 1줄. 로그 줄 수 기반 감사·과금·이상탐지는 이미 어긋나 있을 수 있다.
2. **TLS 검증 실패는 프록시 로그에 안 남는다.** Squid는 200 주고 정상 터널로 기록하는데 앱만 실패하는 패턴 — 사내 CA 미배포·인증서 만료·SAN 불일치가 전부 여기다. 진단은 앱 쪽 `curl -v`의 subject/issuer 줄.
3. **앱의 동시 터널 수 = gateway의 동시 연결 수.** A안에서 Envoy는 TCP 프록시라 downstream:upstream을 1:1로 맺는다. 앱 커넥션 풀 설정(예: Go `MaxIdleConnsPerHost` 기본 2)이 gateway ephemeral port 소모량을 그대로 결정한다.
4. **TLS session resumption ≠ 터널 재사용.** 핸드셰이크 왕복은 줄지만 CONNECT·ACL 심사·로그 줄은 그대로 새로 발생한다 — 다른 층의 최적화다.

## 관련 문서

- [Outbound 집약 설계서 — Istio Egress Gateway로 Squid 경로 일원화](/docs/istio/egress/squid-consolidation-guide/) ([원문 HTML](/docs/istio/egress/squid-consolidation-guide/files/egress-gateway-squid-consolidation-guide.html)) — 이 가이드의 선행 문서. Part 04의 설계 함의가 설계서의 용량 산정으로 이어진다
- [HTTP Tunneling — CONNECT 기초](/docs/networking/http-tunneling-basics/) — CONNECT 개념과 기본 실습. 이 가이드는 그 심화판(바이트 실측·재사용·랩)
- [TLS 1.3 over Squid tunnel](/docs/networking/tls13-over-squid-tunnel/) — 터널 안 TLS 협상의 실측 이웃 문서