이미지·폰트를 텍스트 채널로 나르기 — 바이너리를 WebSocket으로 터널링하기

터널을 처음 만들어 텍스트 페이지를 띄웠을 땐 잘 됐다. 그런데 이미지가 깨지고, 폰트가 안 나오고, CSS가 이상하게 적용됐다. 원인은 하나였다. 나는 응답을 전부 "문자열"로 다루고 있었다.

문제: WebSocket 메시지에 바이너리를 그냥 실으면 깨진다

웹 페이지 하나엔 텍스트(HTML/CSS/JS)만 있는 게 아니다. PNG, WOFF 폰트, PDF 같은 바이너리가 잔뜩이다. 이걸 문자열로 취급해 toString() 하면 바이트가 깨진다. 나는 JSON WebSocket 메시지로 응답을 나르는데, JSON은 텍스트라 바이너리를 그대로 담을 수 없다.

해결 1: 전부 바이너리로 받아서, Base64로 포장

먼저 로컬 클라이언트가 응답을 받을 때 무조건 arraybuffer(바이너리)로 받는다. 텍스트든 이미지든 일단 바이트로 다룬다.

const response = await axios({
  url: `${protocol}://localhost:${localPort}${url}`,
  responseType: "arraybuffer", // 이미지·폰트·텍스트 전부 바이너리로
  decompress: true,            // gzip은 자동 해제
  validateStatus: () => true,  // 4xx·5xx도 그대로 통과
});

그리고 바이너리인 것만 Base64로 인코딩해서 텍스트 JSON에 실을 수 있게 만든다. 어느 쪽인지 isBase64 플래그로 알린다.

const isBinary =
  ct.includes("image/") || ct.includes("video/") ||
  ct.includes("font/")  || ct.includes("application/pdf");

let responseBody, isBase64 = false;
if (isBinary || isSvg) {
  responseBody = Buffer.from(response.data).toString("base64"); // 바이너리 → Base64
  isBase64 = true;
} else {
  responseBody = Buffer.from(response.data).toString("utf8");   // 텍스트는 그대로
}

ws.send(JSON.stringify({ type: "response", requestId, statusCode,
                         headers, body: responseBody, isBase64 }));

서버는 플래그를 보고 되돌린다. Base64면 다시 바이너리로 디코딩해서 응답한다.

pending.res.end(isBase64 ? Buffer.from(body, "base64") : body);

Base64는 용량이 33% 늘지만, JSON/WebSocket이라는 텍스트 통로로 아무 바이트나 안전하게 나를 수 있다. 트레이드오프를 받아들인 셈이다.

해결 2: 빌드 도구가 거짓말하는 Content-Type 교정

여기서 진짜 삽질이 시작됐다. 로컬 개발 서버(특히 Vite)가 엉뚱한 Content-Type을 주는 경우가 있었다. SVG를 text/html로 준다든지, ?import·?url 쿼리가 붙은 모듈을 이상하게 준다든지. 그대로 나르면 브라우저가 파일 종류를 오해해 깨진다.

그래서 파일 확장자와 쿼리를 보고 Content-Type을 강제로 바로잡았다.

let ct = response.headers["content-type"] || "";

// Vite가 변환하는 특수 쿼리(?import, ?url, ?raw 등)는 JS로 취급
if (query && /(import|url|raw|react)/.test(query)) ct = "application/javascript";

// 확장자로 강제 교정
if (urlPath.endsWith(".svg")) ct = "image/svg+xml";
else if (urlPath.endsWith(".png")) ct = "image/png";
else if (urlPath.endsWith(".woff2")) ct = "font/woff2";

해결 3: 중계하면 안 되는 헤더 걸러내기

응답 헤더를 그대로 전달하면 오히려 사고가 난다. 예를 들어:

• content-encoding: gzip — 이미 decompress로 풀었는데 이 헤더가 남아있으면 브라우저가 "압축돼 있네" 하고 또 풀려다 깨진다.
• content-length — 인코딩하며 길이가 바뀌었으니 틀린 값이다.
• content-security-policy, x-frame-options, strict-transport-security — 터널 도메인에서 페이지가 안 뜨게 막을 수 있다.

delete cleanResponseHeaders["content-encoding"];  // 이미 풀었음
delete cleanResponseHeaders["content-length"];     // 길이 바뀜
delete cleanResponseHeaders["transfer-encoding"];
delete cleanResponseHeaders["content-security-policy"];
delete cleanResponseHeaders["x-frame-options"];

리다이렉트(Location) 헤더의 https://localhost도 손봐야 했다. 다만 지금 구현은 http://localhost:8080으로 하드코딩 치환이라 로컬 개발 시나리오 기준이다. 로컬에서 테스트할 땐 동작하지만, 프로덕션에서 외부 방문자가 받으면 자기 컴퓨터의 localhost로 리다이렉트돼 깨진다. 제대로 하려면 터널의 공개 URL로 치환해야 하는데, 아직 남겨둔 한계다.

배운 것

• 텍스트 통로로 바이너리를 나를 땐 Base64가 정석이다. 용량 33% 증가는 대가로 받아들인다.

• Content-Type을 남의 서버가 정확히 준다고 믿으면 안 된다. 특히 개발 서버는 상황에 따라 거짓말을 한다. 확장자·쿼리로 보정하는 안전장치가 필요했다.

• 프록시/중계를 만들 땐 "그대로 전달하면 안 되는 헤더" 가 반드시 있다. 압축·길이·보안 헤더는 중계 계층에서 손봐야 한다. HTTP를 겉핥기로 알 때는 안 보이던 디테일이었다.

• 관련 프로젝트: Custom Tunnel