MCP 요청이 HTTP 431로 거절된다면 도구 인자나 프롬프트를 줄이기 전에 요청 헤더의 크기부터 확인한다. 본문이 작아도 쿠키, 인증 정보, 덧붙인 메타데이터가 크면 요청을 받지 못할 수 있다. 다만 큰 헤더가 언제나 431로 표시되는 것은 아니다. 어느 구간이 어떤 제한으로 거절했는지까지 확인해야 한다.
이 글은 MCP를 HTTP로 연결하는 클라이언트·게이트웨이 운영자를 위한 진단 절차다. HTTP 상태 정의는 RFC 6585, 프로토콜 범위는 MCP 2026-07-28 Streamable HTTP를 기준으로 한다. 2026년 10월 16일 한국시간에 공식 문서를 확인했다. 특정 SDK·NGINX 버전의 장애를 재현한 글은 아니며, 예시는 모두 가상 설계 사례다.
본문 크기와 헤더 크기는 다른 문제다
RFC 6585 §5는 요청 헤더 전체가 너무 크거나 개별 헤더 하나가 너무 클 때 431을 사용할 수 있다고 설명한다. 특정 필드가 원인이라면 응답에서 그 필드를 알려주는 것이 권고되지만, 모든 구현이 상세 정보를 제공한다고 기대해서는 안 된다. 431 공식 정의
| 관측 | 우선 확인할 대상 |
|---|---|
| 431 | 요청 헤더 전체와 개별 필드의 크기 |
| 413 | 요청 콘텐츠의 크기 제한 |
| 415 | 보낸 콘텐츠 형식과 인코딩 |
| 400 | 구체적인 응답·서버 기록. 헤더 크기도 후보지만 단정 금지 |
본문의 arguments를 줄여도 헤더가 그대로라면 431 원인을 건드리지 못한다. 다만 MCP 2026-07-28에서 Mcp-Param-* 형태로 헤더에 반영되는 인자는 본문과 헤더 양쪽에 영향을 줄 수 있으므로, 두 위치를 함께 확인한다. 반대로 인증값을 지워 요청이 통과한 것처럼 보여도, 다른 인증 경로로 바뀌었다면 정상 호출을 검증한 것이 아니다. 같은 대상·메서드·권한 조건에서 비교해야 한다.
첫째, 값을 복사하지 말고 길이와 경로를 기록한다
운영 토큰이나 쿠키를 대화창·이슈·온라인 헤더 분석기에 붙여넣지 않는다. 접근 권한이 있는 관측 도구에서 필드명, 길이, 추가된 구간만 기록한다. 헤더 이름 자체에 고객 식별자가 들어가는 경우도 익명화한다. 로그에 값이 남는 상세 추적 옵션은 무심코 켜지 않는다.
관측 시각 / 시간대:
클라이언트·SDK·프록시·서버 버전:
요청 메서드 / 대상 경로 / HTTP 버전:
응답 상태 / 오류를 만든 구간의 근거:
필드별 길이: 필드명, 바이트 수, 측정 방식
전체 헤더 크기: 측정 지점과 계산 범위
프록시 전후 추가·중복 필드:
본문 크기: 헤더 크기와 별도 기록
비교 요청에서 바꾼 한 가지:
변경 뒤 응답과 실제 작업 결과:문자 수와 바이트 수를 섞지 않는다. 애플리케이션 객체의 대략적인 크기, HTTP/1.1 직렬화 크기, HTTP/2·3에서 압축된 크기는 같은 값이 아니다. 임의 계산값을 게이트웨이의 제한과 바로 비교하지 말고 해당 제품이 무엇을 세는지 먼저 확인한다. 크기 값만 남겨도 민감한 운영 특성이 드러날 수 있으므로 관측 자료의 접근 범위를 제한한다.
둘째, 헤더가 커진 지점을 분리한다
가상 사례 A: 공통 쿠키가 함께 붙는다. 같은 호스트를 쓰는 웹 화면의 쿠키가 MCP 요청에도 전달되는지 확인한다. 필요한 세션 쿠키인지 확인하지 않고 전체 삭제하지 않는다. 불필요한 전송으로 확인된 부분만 시험 환경에서 줄이고, 로그인 상태와 접근 범위가 유지되는지 검사한다.
가상 사례 B: 중간 경로에서 메타데이터가 반복된다. 클라이언트에서는 작은 요청이지만 중간 서비스가 추적·전달용 필드를 누적할 수 있다. 각 구간의 허용된 로그에서 필드명과 길이를 비교한다. 단일 원본 서버의 설정을 늘리기 전에 앞단 게이트웨이가 이미 거절하는지 확인한다. 보안 통제를 우회해 직접 연결하는 방식은 진단의 기본값이 아니다.
가상 사례 C: 인증 헤더 하나가 크다. 인증 구성의 변경 시점과 길이 변화를 대조하되, 서명된 토큰을 임의로 잘라내거나 클레임을 지우지 않는다. 토큰 형식과 발급 정책은 담당자와 검토할 별도 변경이다. 길이만으로 토큰이 잘못됐다고 판단할 수 없다.
셋째, 431이 없다고 헤더 제한을 제외하지 않는다
NGINX의 현재 large_client_header_buffers 문서는 개별 요청 헤더 필드가 버퍼 하나보다 크면 400을 반환한다고 설명한다. 따라서 “431이 아니니 헤더 문제는 아니다”라는 분기는 성립하지 않는다. 이 문서는 설치 버전을 고정한 시험 결과가 아니므로 운영 중인 정확한 버전·유효 설정·HTTP 버전 문서와 다시 대조한다. NGINX 공식 지시어 문서
버퍼 개수와 개별 필드 제한도 혼동하지 않는다. 여러 버퍼를 허용한다고 큰 필드 하나가 자동으로 나뉘어 수용되는 것은 아니다. 또한 헤더 문제를 본문 제한 설정인 client_max_body_size로 해결하려 하지 않는다. 제한을 올리는 변경은 메모리·동시 요청·공격 표면에 영향을 줄 수 있으므로 이 글에서는 붙여넣기용 증설 설정을 제시하지 않는다.
MCP 필수 메타데이터는 유지한다
헤더를 줄일 때 MCP가 요구하는 메타데이터까지 무작정 제거하면 다른 오류로 바뀐다. 적용 중인 프로토콜 버전의 필수 헤더와 본문 조건을 보존하고, 자신이 추가한 불필요한 필드부터 조사한다. 2026-07-28 규격은 Streamable HTTP 원문에서 확인할 수 있다. 오래된 초기화·세션 모델의 예제를 현재 연결에 그대로 섞지 않는다.
수정 완료는 세 가지 증거로 판단한다
첫째, 줄인 필드와 줄인 이유가 기록돼 있어야 한다. 둘째, 같은 권한 조건에서 HTTP 거절이 사라졌는지 확인한다. 셋째, MCP 응답과 실제 요청 목적이 정상적으로 처리됐는지 읽어 확인한다. 상태 코드가 바뀐 것만으로 해결됐다고 쓰지 않는다.
시험은 가능하면 부작용 없는 읽기 요청으로 한다. 이전 쓰기 요청의 실행 여부가 불명확하다면 헤더를 수정했다는 이유만으로 재전송하지 않는다. 대상 상태를 먼저 확인해 중복 변경을 막는다. 운영 환경에서 직접 시험하지 못했다면 결론은 “문서 기반 진단 제안”에 머문다. 이 글 역시 실제 수정 성공을 보고하는 FIX가 아니다.
함께 확인할 글
큰 요청 본문이 413으로 거절되는 경우는 콘텐츠 크기 문제를, 415와 Content-Type·압축 진단은 형식 문제를 다룬다. 이 글의 범위는 요청 헤더의 크기와 거절 위치다.