직접 만든 소프트웨어, 두 가지 개발 기록 구현 구조와 적용 범위, 확인한 기능과 남은 한계를 함께 기록합니다. MediaMTX 스트리밍 제어 서버Docker Compose 구성과 파일·라이브·멀티캐스트 송출 RTSP CCTV 관제·분석 프로그램관제 그룹, 영역·출입선, 이벤트 이력을 연결하는 구조 nginx9 Nginx 정적 파일 404 해결: root·alias 경로와 try_files 점검 순서 파일은 있는데 Nginx 정적 요청이 404라면, 요청 URI에서 실제 파일 경로를 한 번 계산하고 오류 로그가 찾은 경로와 비교하세요. root는 URI를 지정한 디렉터리 뒤에 붙이고, alias는 선택된 location 부분을 다른 경로로 바꿉니다. 호스트에 파일이 존재한다는 사실만으로 Nginx 프로세스가 같은 경로를 본다고 확정할 수 없습니다.Linux의 Nginx가 정적 파일을 직접 제공하는 경우를 다룹니다. Docker를 쓰면 컨테이너 안의 파일 경로를 기준으로 점검합니다. proxy_pass 뒤 애플리케이션이 돌려준 404는 별도 경로입니다. 공식 문서 확인일은 2026년 10월 14일이며 아래 경로는 설명용 예시입니다. 실제 서버에서 재현하거나 설정을 적용했다고 주장하지 않습니다.404 원.. 2026. 10. 15. AWS ALB와 Nginx 비교: 로드 밸런서 비용·TLS·운영 책임 선택 기준 AWS에서 웹 API를 운영할 때 Application Load Balancer(ALB)에 트래픽 분산을 맡길지, Nginx를 직접 운영할지 고민하게 됩니다. AWS의 가용 영역과 컨테이너 서비스에 맞춰 운영 부담을 줄이려면 ALB를 먼저 검토할 수 있습니다. 프록시 설정을 세밀하게 통제하거나 여러 실행 환경에서 같은 구성을 유지해야 한다면 자체 Nginx도 후보입니다. 선택할 때는 서버 한 대의 가격보다 필요한 가용성, TLS 처리, 장애 대응 책임을 같은 조건으로 비교해야 합니다.1. 관리형 서비스와 직접 운영하는 소프트웨어의 차이이 글의 비교 범위는 HTTP·HTTPS 웹 서비스의 요청 분산입니다. ALB는 AWS가 운영하는 관리형 로드 밸런서이고, Nginx Open Source는 설치한 서버나 .. 2026. 10. 5. Nginx WebSocket 연결 실패 해결: Upgrade·101·경로·시간 제한 점검 웹페이지와 API는 정상인데 실시간 알림만 WebSocket connection failed로 끊긴다면 일반 HTTP 응답과 WebSocket 연결을 구분해 확인하세요. Nginx 앞뒤의 프로토콜 전환 헤더, 앱의 WebSocket 경로, 인증·Origin 검사, 유휴 시간 제한이 서로 맞아야 합니다. 먼저 연결 시작에 실패하는지, 시작 후 일정 시간이 지나 끊기는지 나누면 불필요한 설정 변경을 줄일 수 있습니다.1. 브라우저 오류 문구보다 실제 연결 요청을 확인하세요이 글은 일반적인 HTTP/1.1 Upgrade 방식으로 Nginx가 앱 서버에 WebSocket을 전달하는 구성을 설명합니다. MDN WebSocket 서버 안내의 핸드셰이크처럼 성공한 전환은 101 Switching Protocols 응.. 2026. 10. 4. Nginx 499 Client Closed Request 해결: 요청 취소·시간 제한·백엔드 지연 점검 Nginx access log에 499 Client Closed Request가 늘었다면 클라이언트 쪽 연결이 응답 완료 전에 닫혔다는 의미부터 확인해야 합니다. 사용자가 화면을 나갔을 수도 있고, 앱·앞단 프록시의 시간 제한보다 백엔드가 오래 걸렸을 수도 있습니다. Nginx의 시간 제한을 무조건 늘리는 것보다 누가 먼저 연결을 닫았고 어느 구간에서 기다렸는지를 같은 요청의 기록으로 비교해야 원인을 줄일 수 있습니다.1. 499와 504는 관찰한 위치가 다릅니다Cloudflare의 499 공식 설명은 Nginx가 요청을 처리하는 중 클라이언트가 연결을 닫은 상황을 설명합니다. 499는 Nginx에서 쓰는 비표준 값이며, 이미 연결을 끊은 이용자에게 정상적인 HTTP 499 응답이 전달됐다고 가정하면 안.. 2026. 10. 1. Let’s Encrypt 인증서 갱신 실패 해결: Certbot·DNS·포트 80·Nginx 점검 그림: 인증서 만료 확인부터 도메인 검증, 시험 갱신, 웹 서버 재적용까지의 점검 순서입니다.Let’s Encrypt 인증서 갱신에 실패했다면 곧바로 재설치를 반복하지 마세요. 실패 원인은 만료 시각, 도메인 검증 방식, DNS·포트 80 접근, Certbot 설정, Nginx 재적용 중 어디에 있는지 순서대로 확인해야 합니다. 이 글은 운영 서버에서 장애 범위를 좁히는 절차를 다룹니다.1. 만료와 실제 제공 인증서를 구분한다서버에 저장된 인증서 만료일과 사용자에게 보이는 인증서 만료일이 다를 수 있습니다. sudo certbot certificates로 Certbot 관리 인증서를 확인하고, 브라우저 또는 openssl s_client -connect example.com:443 -servername .. 2026. 9. 26. HTTP 429 Too Many Requests 해결: Retry-After·재시도 백오프·Nginx 제한 확인 그림: 429를 받으면 제한 위치와 재시도 시각을 확인하세요.API나 로그인 요청에서 429 Too Many Requests가 나오면 일정 시간 동안 허용량보다 많은 요청을 보낸 것입니다. 즉시 무한 재시도하면 서비스를 더 압박합니다. 어느 계층이 제한했고 Retry-After가 있는지 먼저 확인하세요.1. 429를 반환한 계층을 찾는다브라우저 개발자 도구 또는 curl -i로 응답 헤더, 요청 ID, 시간을 기록하세요. API 제공자, CDN·WAF, Nginx, 앱 각각에서 429를 반환할 수 있습니다. 같은 IP의 모든 사용자가 실패하는지, 한 API 키만 실패하는지 비교하면 제한 기준을 좁힐 수 있습니다.curl -i https://example.com/api/resourcesudo tail -n.. 2026. 9. 25. 이전 1 2 다음
