AI 인프라 / 네트워크 보안 가이드·약 10분 내외

AI 중계 프록시의 멀티 계정 스텔스 아키텍처 — OmniRoute 패킷 4계층 변조와 지문 격리 원리

동일한 PC에서 여러 AI 계정을 동시에 사용할 때 어떻게 빅테크의 동일인 감지(Shadowban/Rate-limit)를 회피할까요? OmniRoute 소스코드로 분석한 L4 TLS 지문부터 L7 헤더 스크러빙, 가상 기기 UUID 격리 및 직렬화 순서 위장까지 4단계 패킷 방어 체계를 파헤칩니다.

아키텍처 구조도

다이어그램 렌더링 중...

1. 동일인 감지(Fingerprinting)의 위협과 첩보원 비유

💡 생활 비유: 첩보원의 위장 신분증과 지문 세척

한 사람이 여러 개의 위장 신분증(다중 계정)을 들고 출입국 심사대(AI 서버)를 통과하려 할 때, 지문과 걸음걸이가 똑같다면 즉시 체포(Shadowban)됩니다.

출입국 도장 (X-Forwarded-For): 내가 중계소(프록시)를 거쳐왔다는 꼬리표입니다. 이를 지우지 않으면 대리인 접속으로 분류되어 차단됩니다.
생체 지문 (Device ID / UUID): 내 컴퓨터 고유의 하드웨어 서명입니다. 계정마다 완전히 다른 가상 지문(UUID)을 새로 찍어줘야 합니다.
택배 포장 필체 (TLS 지문 JA3/JA4): 택배 상자의 내용물(토큰)만 바꾸더라도 상자를 테이핑하는 방식과 필체(TLS 암호화 스위트 조합)가 같으면 같은 사람이 보낸 것임을 알 수 있는 원리입니다.
억양과 정장 (User-Agent & 헤더 순서): 공식 네이티브 앱(macOS 데스크탑)과 동일한 말투(헤더 전송 순서)와 옷차림을 갖춰야 의심을 피할 수 있습니다.
스텔스 라우팅: 단순히 토큰만 바꿔 끼우는 것이 아니라, 패킷의 모든 레이어에서 동일인의 흔적을 말끔히 지우는 기술입니다.

빅테크 AI 기업(Google, OpenAI, Anthropic 등)은 단일 사용자가 무료 티어 한도를 우회하거나 여러 계정을 묶어 쓰는 것을 막기 위해, 단순 IP 외에도 수십 가지의 브라우저/시스템 핑거프린트를 결합하여 동일인을 추적합니다.

📐 AI 탐지망이 감시하는 4대 패킷 지표

중계 흔적 헤더: x-forwarded-for, via 등 프록시 소프트웨어가 기본적으로 덧붙이는 전송 헤더

기기 식별자 일치: 계정이 달라도 컴퓨터 내부에서 생성된 installation_id가 같으면 동일 기기로 판정

헤더 전송 순서 & 압축 포맷: 공식 클라이언트와 다른 헤더 나열 순서 또는 zstd 압축 포맷 누출

TLS 핸드셰이크 지문: 운영체제와 TLS 라이브러리(Node.js/Python)가 만드는 고유 암호화 스위트 서명(JA3/JA4)

2. 4단계 패킷 스텔스 트리아지 의사결정 트리 (Triage Decision Tree)

외부 AI API 요청을 보낼 때 각 패킷 단계별로 어떤 방어 조치를 적용해야 하는지 판단하는 4단계 의사결정 트리입니다.

4단계 패킷 스텔스 의사결정 트리 (Packet Stealth Decision Tree)

다이어그램 렌더링 중...
01

L7 헤더 스크러빙 (Scrubbing)

프록시가 덧붙이는 x-forwarded-for, via 및 불필요한 브라우저 sec-ch-* 헤더를 완전히 제거합니다.

02

가상 기기 ID 격리 (Identity Isolation)

계정마다 영구 고유 Seed를 기반으로 독립된 가상 installation_id와 session_id를 발급합니다.

03

직렬화 순서 정규화 (Serialization)

공식 클라이언트 동작에 맞춰 Authorization 헤더를 맨 끝에 두고 Accept-Encoding을 통일합니다.

04

TLS 지문 및 IP 격리 (TLS & Proxy)

wreq-js 기반 Chrome 124 TLS 핑거프린트와 계정별 독립 Cookie Jar/프록시 IP를 매핑합니다.

3. OmniRoute 소스코드로 본 헤더 세척과 직렬화 위장 기법

OmniRoute의 `antigravityHeaderScrub.ts`는 프록시 존재를 누출할 수 있는 헤더들을 사전에 정의된 블랙리스트로 정밀하게 필터링합니다.

antigravityHeaderScrub.ts
// 제거 대상 블랙리스트 헤더
const HEADERS_TO_REMOVE = [
  // 1. 프록시 역추적 헤더
  "x-forwarded-for", "x-forwarded-host", "x-forwarded-proto", "forwarded", "via",
  // 2. 타 SDK 지문 (Claude Code / Stainless SDK 누출 방지)
  "x-stainless-lang", "x-stainless-os", "x-stainless-arch", "x-stainless-package-version",
  // 3. 브라우저/Electron 전용 누출 헤더
  "sec-ch-ua", "sec-ch-ua-mobile", "sec-ch-ua-platform", "sec-fetch-mode", "priority"
];

export function scrubProxyAndFingerprintHeaders(headers: Record<string, string>) {
  const cleaned: Record<string, string> = {};
  let authorizationValue: string | undefined;

  for (const [key, value] of Object.entries(headers)) {
    const lowerKey = key.toLowerCase();
    if (lowerKey.startsWith("x-omniroute-") || HEADERS_TO_REMOVE.includes(lowerKey)) {
      continue;
    }
    if (lowerKey === "authorization") {
      // Authorization을 맨 마지막으로 지연시켜 직렬화 순서를 공식 앱과 100% 일치시킴
      authorizationValue = value;
      continue;
    }
    cleaned[key] = value;
  }
  // Node.js 표준 인코딩 강제 (Electron의 zstd 누출 차단)
  cleaned["Accept-Encoding"] = "gzip, deflate, br";
  if (authorizationValue !== undefined) {
    cleaned["Authorization"] = authorizationValue;
  }
  return cleaned;
}

🔍 직렬화 순서(Order)가 중요한 이유

HTTP 헤더는 명세상 순서가 무관하지만, 보안 탐지 엔진은 클라이언트 라이브러리가 헤더를 직렬화(Serialization)하는 순서를 분석합니다.

Node.js 네이티브 앱: `Host` ➔ `User-Agent` ➔ `Content-Type` ➔ `Authorization` 순으로 패킷을 구성
일반 프록시: `Authorization`을 맨 위에 두거나 알파벳 순 정렬 ➔ 탐지 엔진에 즉시 적발
OmniRoute의 해법: Authorization을 지연 삽입하여 네이티브 앱의 바이트 순서를 그대로 복제

4. 가상 기기 식별자(UUID)와 macOS 클라이언트 위장

실제 서버가 Ubuntu 리눅스이더라도, AI 업스트림 서버에는 가장 널리 사용되는 공식 클라이언트 환경인 `darwin/arm64 (macOS)`로 완벽히 위장합니다.

antigravityHeaders.ts
const ANTIGRAVITY_OS_TYPE = "darwin";
const ANTIGRAVITY_ARCH = "arm64";

// 공식 macOS 데스크탑 IDE User-Agent 위장
export function antigravityIdeUserAgent(version = "1.1.27"): string {
  return `antigravity/ide/${version} ${ANTIGRAVITY_OS_TYPE}/${ANTIGRAVITY_ARCH}`;
}

// 계정별 독립 가상 UUID 생성 (Seed 기반 결정론적 해시)
export function deriveStableUUIDv4(seed: string): string {
  const digest = createHash("sha256").update(seed).digest();
  const bytes = Buffer.from(digest.subarray(0, 16));
  bytes[6] = (bytes[6] & 0x0f) | 0x40; // RFC4122 v4
  bytes[8] = (bytes[8] & 0x3f) | 0x80;
  return [
    bytes.subarray(0, 4).toString("hex"),
    bytes.subarray(4, 6).toString("hex"),
    bytes.subarray(6, 8).toString("hex"),
    bytes.subarray(8, 10).toString("hex"),
    bytes.subarray(10, 16).toString("hex"),
  ].join("-");
}

5. 실습: 내 프록시의 패킷 세척 상태 검증하기

내가 구축한 중계 서버나 로컬 프록시가 `X-Forwarded-For` 등의 추적 헤더를 실제로 안전하게 제거하고 있는지 `curl`을 통해 직접 검증해볼 수 있습니다.

터미널 검증
# 1. 추적 헤더를 일부러 실어 로컬 중계 프록시로 전송 테스트
curl -s -X POST "http://localhost:20128/v1/chat/completions" \
  -H "Content-Type: application/json" \
  -H "X-Forwarded-For: 203.0.113.195" \
  -H "Via: 1.1 my-custom-proxy" \
  -H "Authorization: Bearer sk-test-key" \
  -d '{
    "model": "auto/best-coding",
    "messages": [{"role": "user", "content": "ping"}],
    "max_tokens": 5
  }'

📋 결과 화면 해석 요령

정상 (스텔스 성공): 중계 서버 로그에서 `X-Forwarded-For` 및 `Via` 헤더가 감지되더라도 업스트림으로 나가는 패킷에서는 말끔히 제거되고, `User-Agent`가 `antigravity/ide/... darwin/arm64`로 치환되어 200 OK 응답이 반환됩니다.

비정상 (누출 위험): 업스트림 서버로부터 `403 Forbidden` 또는 `429 Too Many Requests`와 함께 프록시 의심 플래그가 반환되는 경우 헤더 스크러빙 미들웨어가 누락되었는지 점검해야 합니다.

6. 실무 적용 시 보안 및 운영 수칙

❌ 위험한 멀티 계정 호출 방식

  • 동일한 HTTP 클라이언트 인스턴스에서 토큰만 바꿔가며 호출 (세션 쿠키 및 소켓 풀 공유)
  • X-Forwarded-For 등 기본 프록시 헤더를 그대로 통과시키는 범용 Nginx/Caddy 중계
  • Linux/Python 기본 User-Agent 또는 제각각인 브라우저 sec-ch-* 헤더 누출

✅ 안전한 스텔스 중계 방식

  • 계정마다 독립된 고유 Seed로 생성된 가상 installation_id 매핑
  • L7 헤더 스크러빙으로 모든 프록시 및 브라우저 누출 헤더 사전 삭제
  • 공식 클라이언트 규격(macOS darwin/arm64)으로 User-Agent 및 헤더 순서 고정
  • 필요 시 wreq-js를 통한 Chrome 124 TLS 핑거프린트 스푸핑 적용
공식 유료 API 키를 직접 사용하는 경우에는 위와 같은 스푸핑이 불필요하지만, IDE 연동형 세션을 다중화할 때는 패킷 정규화가 안정적인 운영의 필수 조건입니다.

IJM 인프라팀

AI 플랫폼 & 시스템 아키텍트

OmniRoute 소스코드 분석을 통해 확인된 4계층 패킷 변조 및 지문 격리 기법은 대규모 AI 계정 풀을 안전하고 신뢰성 있게 운영하기 위한 핵심 기술 표준입니다.