# FastCGI: 리버스 프록시용으로는 30년이 지나도 여전히 더 나은 프로토콜 > Clean Markdown view of GeekNews topic #29033. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=29033](https://news.hada.io/topic?id=29033) - GeekNews Markdown: [https://news.hada.io/topic/29033.md](https://news.hada.io/topic/29033.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2026-04-30T11:01:08+09:00 - Updated: 2026-04-30T11:01:08+09:00 - Original source: [agwa.name](https://www.agwa.name/blog/post/fastcgi_is_the_better_protocol_for_reverse_proxies) - Points: 1 - Comments: 2 ## Topic Body - **장기 실행 백엔드**에 소켓으로 요청을 넘기는 프록시 프로토콜로서, 기존 HTTP 핸들러 구조를 거의 바꾸지 않고 적용 가능함 - **HTTP/1.1 역프록시**는 메시지 경계 해석이 구현마다 어긋나기 쉬워 desync와 request smuggling 같은 심각한 보안 문제를 계속 만들 수 있음 - **FastCGI**는 1996년부터 명확한 메시지 프레이밍을 제공해 왔고, 클라이언트 헤더와 프록시가 추가한 신뢰 정보를 구조적으로 분리해 줌 - Go의 `net/http/fcgi`는 `REMOTE_ADDR`를 `Request.RemoteAddr`에 채우고 HTTPS 여부도 `Request.TLS`에 반영해, **신뢰 정보 전달**을 별도 미들웨어 없이 처리할 수 있음 - WebSockets 미지원, 약한 도구 생태계, 일부 워크로드의 **낮은 처리량** 같은 한계는 있지만, WebSockets가 필요 없고 성능이 충분하다면 여전히 실용적인 선택지로 보임 --- ### FastCGI의 위치와 적용 방식 - **FastCGI**는 파일별 프로세스 실행 방식에만 쓰이는 것이 아니라, **장기 실행 데몬**에 TCP 또는 UNIX 소켓으로 요청을 보내는 프록시-백엔드 프로토콜로도 쓸 수 있음 - Go에서는 [`net/http/fcgi`](https://pkg.go.dev/net/http/fcgi) 패키지를 가져오고 `http.Serve`를 `fcgi.Serve`로 바꾸는 정도로 적용 가능함 - 기존 핸들러는 그대로 `http.ResponseWriter`와 `http.Request`를 사용함 - 애플리케이션의 나머지 구조도 그대로 유지됨 - **Apache**, **Caddy**, **nginx**, **HAProxy** 같은 주요 프록시는 FastCGI 백엔드를 지원하며 설정도 단순한 편임 ### HTTP를 백엔드 프로토콜로 쓸 때의 파싱 문제 - HTTP reverse proxying은 **보안 지뢰밭**에 가깝고, Discord 미디어 프록시의 [desync 취약점](https://tmctmt.com/posts/http-desync-in-discord/)처럼 사적인 첨부파일을 엿볼 수 있는 문제도 계속 나타남 - **HTTP/1.1**은 겉보기에는 단순한 텍스트 프로토콜이지만, 같은 메시지를 표현하는 방식이 지나치게 많고 예외 처리도 많아 구현마다 해석이 달라지기 쉬움 - 가장 큰 문제는 HTTP 메시지에 **명시적 프레이밍**이 없다는 점임 - 메시지 끝을 메시지 자체가 여러 방식으로 설명함 - 구현체마다 메시지 종료 지점과 다음 메시지 시작 지점을 다르게 해석할 수 있음 - 이런 불일치는 [HTTP desync attacks](https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn) 또는 request smuggling의 기반이 되며, 리버스 프록시와 백엔드가 메시지 경계를 다르게 이해하면서 심각한 보안 문제를 만듦 - 파서 차이를 계속 패치하는 방식은 **근본 해법**이 되기 어려움 - [James Kettle](https://jameskettle.com/)은 새로운 유형을 계속 찾아내고 있음 - 지난해 추가 사례를 찾은 뒤 ["HTTP/1.1 must die"](https://http1mustdie.com/)라는 표현까지 사용함 ### FastCGI와 HTTP/2의 메시지 경계 처리 - **HTTP/2**는 프록시와 백엔드 사이에서 일관되게 사용할 경우 메시지 경계를 분명히 해 desync 문제를 해결할 수 있음 - **FastCGI**는 이런 명확한 경계 구분을 1996년부터 더 단순한 프로토콜로 제공해 왔음 - nginx는 첫 릴리스부터 FastCGI 백엔드를 지원했지만, **HTTP/2 백엔드** 지원은 2025년 후반에야 추가됨 - Apache의 HTTP/2 백엔드 지원은 여전히 ["experimental"](https://httpd.apache.org/docs/trunk/mod/mod_proxy_http2.html) 상태로 남아 있음 ### 신뢰할 수 없는 헤더 문제와 FastCGI의 분리 방식 - desync만의 문제가 아니라, HTTP는 **실제 클라이언트 IP**, 프록시가 처리한 인증 사용자명, mTLS에서의 클라이언트 인증서 정보처럼 프록시가 신뢰해서 전달해야 하는 데이터를 견고하게 실어 나르는 방법도 부족함 - 현실적으로는 이런 정보를 HTTP 헤더에 넣게 되는데, 프록시가 추가한 **신뢰 데이터**와 클라이언트가 보낸 **비신뢰 헤더** 사이에 구조적 구분이 없음 - `X-Real-IP` 같은 헤더는 실제 클라이언트 IP 전달에 자주 쓰이지만, 프록시가 대소문자 변형까지 포함한 기존 헤더를 모두 완전히 제거한 뒤 다시 넣어야 안전해짐 - 이 방식은 [매우 위험한 지형](https://adam-p.ca/blog/2022/03/x-forwarded-for/)이며, 백엔드가 공격자가 넣은 데이터를 신뢰하게 되는 경로가 많음 - 프록시는 `X-Real-IP`뿐 아니라 이런 용도의 **어떤 헤더든** 전부 지워야 함 - 예를 들어 Chi 미들웨어는 클라이언트 실제 IP를 정할 때 [`True-Client-IP`를 먼저 확인](https://adam-p.ca/blog/2022/03/x-forwarded-for/#go-chichi)하고, 없을 때만 `X-Real-IP`를 사용함 - 프록시가 `X-Real-IP`를 제대로 처리해도 공격자가 `True-Client-IP`를 보내면 문제가 생길 수 있음 - **FastCGI**는 클라이언트 헤더와 프록시가 추가한 정보를 **도메인 분리** 방식으로 구분함 - 둘 다 키/값 파라미터 목록으로 전달되지만, HTTP 헤더 이름에는 `HTTP_` 접두사가 붙음 - 따라서 클라이언트가 보낸 헤더가 프록시의 신뢰 데이터로 해석되는 구조가 성립하지 않음 ### Go에서의 FastCGI 신뢰 정보 처리 - FastCGI는 실제 클라이언트 IP를 전달하기 위한 `REMOTE_ADDR` 같은 **표준 파라미터**를 정의함 - Go의 `net/http/fcgi`는 이 값을 자동으로 `http.Request`의 `RemoteAddr`에 채워 넣어 별도 미들웨어 없이 동작함 - 프록시는 HTTPS 사용 여부, 협상된 TLS cipher suite, 클라이언트 인증서 같은 정보도 **비표준 파라미터**로 전달할 수 있음 - Go는 요청이 HTTPS를 사용한 경우 `Request`의 `TLS` 필드를 nil이 아닌 값으로 자동 설정함 - 비어 있더라도 HTTPS 강제 여부를 확인하는 데 유용함 - [`fcgi.ProcessEnv`](https://pkg.go.dev/net/http/fcgi#ProcessEnv)로 프록시가 보낸 전체 신뢰 파라미터 집합에 접근 가능함 ### 보급이 더딘 이유와 현실적 한계 - FastCGI가 더 낫다면 왜 널리 쓰이지 않는지에 대해, **이름 자체의 시대감**과 HTTP reverse proxy 보안 문제에 대한 인식 부족이 함께 작용한 것으로 보임 - [Watchfire](https://www.cgisecurity.com/lib/HTTP-Request-Smuggling.pdf)는 2005년에 이미 desync 공격을 다뤘고, 해결이 쉽지 않다는 경고도 남겼지만 이런 공격은 10년 넘게 제대로 주목받지 못함 - FastCGI는 오늘날에도 실사용 가능하며, [SSLMate](https://sslmate.com/)에서는 10년 넘게 프로덕션에서 사용 중임 - 다만 **오래된 기술**이라 약점도 있음 - WebSockets 지원을 위해 업데이트되지 않았음 - 도구 생태계가 부족함 - 예를 들어 curl은 FTP, Gopher, SMTP까지 지원하지만 FastCGI 요청은 보낼 수 없음 - Go FastCGI 서버를 여러 reverse proxy 뒤에서 벤치마크했을 때, 일부 워크로드는 **HTTP/1.1 또는 HTTP/2보다 처리량이 낮았음** - 이를 프로토콜 자체의 한계라기보다 FastCGI 코드 경로가 HTTP만큼 최적화되지 않은 결과로 봄 ### 최종 판단 - WebSockets가 필요 없고 현재 성능이 충분하다면 **FastCGI는 여전히 쓸 만한 선택지**임 - 병목이 생기더라도 HTTP reverse proxying의 복잡성과 보안 악몽을 감수하기보다는 **하드웨어 추가**를 택하는 쪽이 낫다고 봄 ## Comments ### Comment 56600 - Author: rtyu1120 - Created: 2026-04-30T11:31:57+09:00 - Points: 1 Lobsters 댓글에서 찾은 Twisted의 FastCGI 코멘트가 인상적이네요 https://web.archive.org/web/20160723091923/http://twistedmatrix.com/trac/attachment/ticket/3062/fastcgi.py ### Comment 56595 - Author: neo - Created: 2026-04-30T11:01:10+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47950510) - 글 취지에는 동의함. 이런 용도라면 **FastCGI**가 HTTP보다 낫다고 봄 **WAS(Web Application Socket)** 라는 프로토콜도 알리고 싶음. 16년 전에 직장에서 FastCGI도 충분히 좋지 않다고 느껴 직접 설계했음 메인 소켓 프레이밍 대신 제어 소켓 1개와 raw 요청/응답 바디용 파이프 2개를 쓰고, WAS 앱과 웹 서버 모두 pipe에 대해 `splice()`를 활용할 수 있음 프레이밍이 필요 없고, 요청 취소도 가능하며, 세 개의 파일 디스크립터를 언제나 복구할 수 있게 했음 수년간 내부 애플리케이션과 웹호스팅 환경에서 써 왔고, **PHP SAPI**도 직접 작성했음. 꽤 많은 웹사이트가 내부적으로 WAS 위에서 동작함 전부 오픈소스임 library: [https://github.com/CM4all/libwas]() documentation: [https://libwas.readthedocs.io/en/latest/]() non-blocking library: [https://github.com/CM4all/libcommon/tree/master/src/was/asyn...]() our web server: [https://github.com/CM4all/beng-proxy]() WebDAV: [https://github.com/CM4all/davos]() PHP fork with WAS SAPI: [https://github.com/CM4all/php-src]() - **FastCGI**와 HTTP는 같은 층위가 아님 HTTP는 브라우저와 서버 같은 양끝 간 데이터 전달용이고, FastCGI는 서버와 애플리케이션 사이에서 그 데이터를 처리하는 용도임 방금 글을 훑어봤는데 저자가 둘을 서로 대체 가능한 것처럼 헷갈리게 쓰는 듯함. 실제로는 전혀 그렇지 않음 참고로 나도 웹 고객 서비스에 **fcgi**를 10년 동안 써 왔음 - 이 글은 빠진 내용이 많아서 오히려 흥미로움 **FastCGI vs. SCGI vs. HTTP** 논쟁이 한창일 때 Web2.0 스타트업을 창업했고 프런트엔드 스택을 직접 구성했는데, 결국 HTTP가 이긴 이유는 단순함 때문이었음 게이트웨이에서 이미 처리해야 하는 HTTP를 그대로 쓰면 다른 프로토콜을 스택에 추가할 필요가 없었고, 덕분에 reverse proxy를 여러 단계로 넣거나 인증·세션·SSL 종료·DDoS 필터링처럼 횡단 관심사를 역할별 서버로 분리하는 구성이 아주 쉬워졌음 개발 환경에서는 앱 서버에 HTTP로 바로 붙고, 운영에서는 SSL·인증·남용 탐지를 reverse proxy가 담당하는 식으로 같은 앱 서버를 그대로 재사용할 수 있었음 당시엔 **nginx**가 대부분의 FastCGI/SCGI 모듈보다 훨씬 빠르고 안정적이었던 것도 컸음. 처음엔 `HTTP -> Lighttpd -> FastCGI -> Django`로 구성했지만 그냥 nginx를 쓰는 편이 훨씬 빨랐음 HTTP 사용은 웹판 **End-to-End Principle**처럼 작동했음. 네트워크와 프로토콜은 전달 내용에 무관해야 하고, 애플리케이션 로직은 필터링·리다이렉트하는 네트워크 노드가 아니라 끝단에 있어야 한다는 생각임 다만 글이 짚는 핵심은 보안 측면에서는 **최소 권한 원칙**을 따르는 편이 더 나을 때가 많다는 것임. 예상한 통신만 allowlist로 통과시켜야 다른 지점의 침해에 무심코 기여하지 않게 됨 결국 이 둘 사이엔 긴장이 있음. E2E는 유연성을 주지만 그 유연성이 악용될 여지도 키우고, PoLP는 보안을 주지만 설계한 것만 할 수 있게 되어 새 요구사항에 적응하기 어려워짐 [1] [https://en.wikipedia.org/wiki/End-to-end_principle]() [2] [https://en.wikipedia.org/wiki/Principle_of_least_privilege]() - 그 비유는 잘 맞지 않는다고 봄. 특히 **connection caching**과 multiplexing 맥락에선 더 그럼 중간 게이트웨이가 여러 HTTP 요청을 다른 HTTP 채널 하나로 multiplex하고, 그 채널이 listening service까지 직접 이어지며 애플리케이션 소켓 전에 demultiplex되지 않는다면, 그건 end-to-end 논리를 여러 방식으로 근본적으로 깨뜨림 1:1 연결 대칭성이 유지될 때만 그 비유가 그나마 성립함 reverse proxy 취약점들은 전부 end-to-end를 어긴 데서 직접 비롯됐다고 봄 그 비유가 맞다면 여러 MX를 거치는 **SMTP** 전달도 end-to-end여야 하는데, 실제로는 아니고 reverse proxy와 비슷한 문제들, 예컨대 메시지 경계 desync도 많이 생김 HTTP 요청을 메시지에 대응시키려는 의도는 알겠지만, 실제 TCP·HTTP 시맨틱과 온갖 프로토콜 세부사항 때문에 금방 무너짐 end-to-end 원칙은 시맨틱을 대충 다루는 걸 허용하지 않음. 상태 관리와 전송 계층 경계에 매우 엄격한 규율을 요구함. **대충 end-to-end 비슷한 것**은 end-to-end가 아님 - 웹앱 개발자에게 **HTTP semantics**는 유용하지만, HTTP wire protocol 자체는 형편없음 예를 들어 multiplexing도 HTTP 2.0 전까지 없었고, 그래서 reverse proxy와 backend 사이 통신에 HTTP를 그대로 쓰는 건 낭비가 큼 보안 문제도 있음. 파서가 서로 요청 경계가 어디서 끝나는지조차 다르게 해석할 수 있음 Google도 오래전부터 프런트 웹 서버와 애플리케이션 사이에서는 HTTP를 자체 **Stubby** 프로토콜로 감싸서 씀 HTTP wire protocol보다 훨씬 빠르고 기능도 많음. 보통 회사엔 과하지만, 규모가 커지면 다른 wire protocol과 그 주변 툴링을 직접 만드는 비용이 충분히 정당화됨 - 데이터센터 내부에서 **end-to-end principle**을 적용하는 건 별 의미가 없고, 글이 보여주듯 오히려 불안전한 동작을 허용하게 됨 - 내가 nginx에서 싫어하는 건 **문서화**임. 사실상 거의 쓸모가 없다고 느낌 httpd도 어느 순간 설정을 어렵게 만드는 방향으로 갔고, 설정 포맷을 갑자기 바꾼 시점에 버렸음 적응할 수는 있었겠지만 그 대신 lighttpd로 옮겼고, 이후엔 ruby가 설정 생성을 자동화해서 기술적으로는 다시 httpd로 돌아갈 수도 있음 그래도 돌아가고 싶진 않음. 웹서버 개발자라면 사용자가 새 포맷에 억지로 맞추게 만드는 일을 신중히 봐야 함 정말 단순한 결정으로 설정 포맷을 바꿀 거라면, 최소한 **yaml 설정** 같은 걸 추가 옵션으로라도 제공해서 갑자기 새로운 if-clause 스타일 설정문을 강요하지 않았으면 함 - **WHATWG streams**가 브라우저에 널리 퍼진 지금은, 장수명 HTTP 요청 위에 자체 WebSocket 비슷한 걸 구현하기가 꽤 쉬움 그냥 바이트 스트림을 보내고 각 메시지 앞에 헤더를 붙이면 되며, 많은 경우 길이 값 하나면 충분함 장점도 있음. WebSocket처럼 서버 계층에 별도 특수 경로가 필요 없고, **backpressure**를 쓸 수 있으며, HTTP/2·HTTP/3 개선을 공짜로 가져오고, 프레이밍 오버헤드도 더 낮음 다만 AFAIK 요청 바디를 계속 스트리밍하면서 동시에 응답을 받는 건 아직 지원되지 않아서, 완전한 양방향 스트리밍에는 요청 두 개가 필요함 - 오래된 **plain CGI**를 다시 발견했는데, 우리 플랫폼에서 사용자가 커스텀 페이지를 vibe code 하게 만들기엔 아주 좋음 [1] 기본 제공 기능으로는 task list와 data viewer가 있지만, 사용자는 종종 Kanban 뷰나 데이터 필터·차트가 들어간 커스텀 대시보드처럼 훨씬 더 세밀한 맞춤 구성을 원함 이 박스에는 coding agent가 있어서 우리가 전통적인 report builder를 만드는 대신 사용자가 원하는 걸 직접 코드로 만들 수 있음 Go stdlib가 서버 측과 사용자 공간 양쪽에서 지원이 좋고, coding agent가 `page-name/main.go`를 만들어 CGI로 통신하게 하면 서버가 요청을 거기로 위임함 데이터 규모와 페이지뷰가 전부 **person scale**이라 FastCGI 같은 최적화가 딱히 필요하지도 않음 에이전트 시대엔 옛 기술이 다시 새로워짐 1. [https://housecat.com]() - CGI는 FastCGI와 달리 HTTP 헤더를 **환경 변수**로 전달해서 꽤 큰 함정이 있다는 걸 조심해야 함: [https://httpoxy.org/]() Go의 CGI 서버 구현은 `$HTTP_PROXY`를 설정하지 않아서 그 부분은 안전하지만, 그래도 CGI가 환경 변수를 쓰는 방식은 여전히 마음에 들지 않음 - reverse proxy 쪽은 대체로 단순한 작업만 해서 **Nginx** 내장 기능만 써도 충분했음 그래도 더 복잡한 게 필요할 때 FastCGI를 쓰겠다는 발상은 나에겐 떠오르지 않았을 것 같음 10년쯤 전에 C++ 코드 일부를 웹에서 돌리려고 FastCGI를 조금 써 보긴 했지만, 그 뒤로는 거의 쓰지 않았음 - 요즘은 **embedded server**가 훨씬 더 흔함 애플리케이션 안에 HTTP 서버를 직접 넣고, 게이트웨이 없이 필요한 일을 그냥 처리하면 됨 - Red Hat 계열에서 배포되는 PHP/Apache 구성은 **FPM(FastCGI Process Manager)** 임 RHEL 배포판에서 FastCGI를 다른 데서도 쓰는지는 모르겠음 `$ rpm -qi php-fpm | grep ^Summary` `Summary : PHP FastCGI Process Manager` - 찾는 건 FPM이 아니라 **mod_proxy_fcgi**일 가능성이 큼 Fedora의 `httpd-core` 패키지에는 포함돼 있음. RHEL은 잘 모르겠음: [https://packages.fedoraproject.org/pkgs/httpd/httpd-core/fed...]() - **uwsgi protocol**도 있음 이것도 사실상 거의 모든 것에 대한 RPC 같은 성격임 - **FCGI**는 오케스트레이션 시스템이기도 함 부하가 올라가면 서버 태스크를 더 띄우고, 부하가 줄면 내리며, 태스크가 죽으면 새 복사본을 띄움 일종의 단일 시스템 Kubernetes 같음 - 내 경험상 그 기능은 그다지 좋지 않았음 듣기엔 좋아 보이지만, 평소 저부하에서는 잘 돌다가 고부하가 오면 worker를 더 생성하면서 메모리를 바닥내는 일이 자주 생김 그래서 **정적 worker 수**를 두는 편이 대체로 더 나았음 다만 crash recovery는 필요하다면 유용함 - 우리도 정확히 그런 식으로 사용했음 - HTTP 헤더의 **부조리함**을 잠깐만 감상해도 좋겠음 `True-Client-IP`가 없을 때만 `X-Real-IP`를 쓴다면, 프록시가 `X-Real-IP`를 제대로 넣더라도 공격자가 `True-Client-IP` 헤더를 보내면 그대로 당할 수 있음 `X-Forwarded-For`, `X-Real-IP`, CDN마다 제각각인 커스텀 헤더까지 있고, 어떤 건 콤마로 구분된 리스트이며 보통 우리 own LB의 IP까지 쓸모없이 붙어 들어감 왜 그런지는 알지만 전혀 도움이 되지 않음 게다가 이런 헤더는 전부 악의적인 user-agent가 삽입할 수도 있음. 신뢰 가능한 서버들이 파이프라인에서 중요한 정보를 어떻게 전달할지 아무도 합의를 못 한 셈 같음 이런 혼란은 **User-Agent** 헤더의 부조리함과도 잘 어울림 그쪽은 Apple이 프라이버시를 명분으로 완전히 가짜 정보, 예를 들면 거짓 OS 버전 같은 헛소리를 보내기로 하면서 한층 더 극단으로 갔음 - 이 주장엔 일리가 많지만, **FastCGI**는 `PATH_INFO` 같은 부분에서 CGI/1.1을 따르기 때문에 손실이 생김 URL 디코딩이 강제되어 **encoded slash**인 `%2F`를 표현할 수 없음 구현에 따라 경로의 `//`를 `/`로 합치기도 하는데, 이건 여러 HTTP 구현에도 있는 문제이긴 함 표현력 면에서는 HTTP보다 떨어지고, 그 차이가 중요할지는 애플리케이션에 달렸음 나는 URL을 정확하게 다루는 쪽을 더 선호함