직접 만든 소프트웨어, 두 가지 개발 기록 구현 구조와 적용 범위, 확인한 기능과 남은 한계를 함께 기록합니다. MediaMTX 스트리밍 제어 서버Docker Compose 구성과 파일·라이브·멀티캐스트 송출 RTSP CCTV 관제·분석 프로그램관제 그룹, 영역·출입선, 이벤트 이력을 연결하는 구조 reverseproxy2 Nginx 413 Request Entity Too Large 해결: 업로드 용량·프록시·Docker 점검 실제 전송 노트: 413이 Nginx에서 났는지 앱에서 났는지 확인했습니다2026년 10월 12일 별도 Docker의 Nginx 1.30.4·Node.js 24.21.0(Linux arm64)에 비민감 A 바이트로 만든 본문을 실제 전송했습니다. 아래 기존 인코딩 계산과는 별개인 HTTP 재현 시험입니다. 실제 고객 파일·영상·운영 서버는 사용하지 않았습니다.작은 시험 한도로 경계와 차단 계층을 분리했습니다Nginx 시험 서버 두 곳의 client_max_body_size를 각각 3k(3072바이트), 6k(6144바이트)로 정했습니다. 같은 앱은 요청 본문을 실제로 센 뒤 4096바이트 초과이면 413을 반환하게 작성했습니다. 앱의 4096바이트는 이번 예제의 정책이지 Node.js나 모든 프레임워크의.. 2026. 9. 23. Nginx 502 Bad Gateway 해결: Docker upstream·포트·헬스체크 점검 실제 재현 노트: 같은 502라도 고칠 위치가 달랐습니다2026년 10월 12일 별도의 로컬 Docker 시험에서 Nginx 1.30.4와 Node.js 24.21.0(Linux arm64)을 실행했습니다. 아래는 운영 장애 경험이 아니라, 비민감 예제 앱에 실제 HTTP 요청을 보내고 Nginx 오류·접근 로그와 앱 수신 로그를 대조한 결과입니다. 시험 네트워크는 외부 연결을 막았고 호스트 포트는 공개하지 않았습니다.주소만 바꾼 세 요청과 앱이 반환한 502앱은 별도 컨테이너의 0.0.0.0:3000에서 수신하도록 했습니다. Nginx의 연결 제한은 1초, 읽기 제한도 1초였으며 자동 다음 upstream 재시도는 껐습니다. 아래 세 proxy_pass는 실제 시험에 사용한 설정의 핵심 부분입니다.# .. 2026. 9. 22. 이전 1 다음