발생일: 2017.12.06 키워드: nginx, default_server, 기본 server 문제: 엥?? 도메인이 다른 전혀 관련 없는 웹페이지가 우리 서비스를 프록시로 걸어 제공하고 있었다. 어처구니가 없는 행동이지만, 그 전에 왜 nginx는 도메인이 다른 접근에 응답하고 있었던 걸까? nginx 설정의 서버 블럭에는 아래와 같이 server_name 이 명시되어 있었다. server { server_name ohgyun.com; ... } 해결책: nginx의 "첫 번째" 서버 블럭은 server_name 이 매칭되지 않았을 때 동작하는 기본 서버 블럭이다. 서버 블럭을 하나만 정의했었기 때문에, 도메인이 매칭되지 않았을 때에도 동일하게 첫 번째 블럭이 실행된 것이 문제였다. 아래와 같이 기본..
발생일: 2017.07.31 키워드: nginx, 용량, 로그 용량, copytruncate, logrotate, 로그 로테이트 문제: 서버 용량이 가득 차서 리스타트에 실패하는 문제가 발생했다. nginx 로그 때문으로 추측되는데, 실제로 로그 디렉토리 내의 로그 파일의 용량은 문제가 될 만큼 크지 않다. 뭐가 문제일까? 해결책: nginx 로그는 로테이트해 S3로 업로드한 후에 삭제한다. 확인해보니, 원인은 로그가 제대로 로테이트되지 않고 프로세스가 삭제된 기존 파일을 계속 물고 있었기 때문이다. 로그 로테이트 옵션에 copytruncate 을 추가하는 것으로 해결했다. 아래는 작업과 관련된 스크립트: # 현재 머신의 용량을 확인해본다 df -h # 어떤 디렉토리에서 가장 많이 차지하는지 확인한다 s..
발생일: 2017.01.05 키워드: AWS ELB, x-forwarded-for, IP 스푸핑, IP Spoofing 문제: 우린 앱서버로 node.js의 express를 사용한다. express 로그에서 요청 IP를 파악할 땐, X-Forwarded-For 헤더의 값을 참조한다. 헌데, 로그를 살펴보니 X-Forwarded-For 헤더에 예상했던 것보다 많은 IP가 포함되어 있는 경우가 있다. 프록시를 여러 번 걸쳐 들어온 것 같은 요청도 있고, IP 스푸핑으로 보이는 것들도 있다. X-Forwarded-For 헤더의 여러 IP 중에서 어떤 걸 진짜 사용자의 IP라고 보면 될까? 해결책: 우리는 express 서버 앞 단에 AWS ELB(엘라스틱 로드밸런서)와 nginx를 뒀다. Client -> E..
발생일: 2016.10.19 키워드: nginx log rotation, logrotate, logrotated, 로그 로테이트, log rotate, midsize, maxsize, size 문제: nginx 로그를 특정 주기로 저장해서 AWS의 S3에 저장하고 싶다. 어떻게 접근하면 될까? 해결책: 로그를 주기적으로 분리 저장하는 목적의 모듈이 있다. log rotate 모듈이고, 대부분의 유닉스 시스템엔 이미 설치되어 있다. 검색해보니, 워낙 잘 작성한 포스트가 많아 링크로 대체한다. How To Configure Logging and Log Rotation in Nginx on an Ubuntu VPS - https://www.digitalocean.com/community/tutorials/ho..
발생일: 2016.10.21 키워드: nginx, log, access log, nginx logging is not working 문제: nginx 에서 access_log가 제대로 출력되지 않는다. 해결책: 몇 가지 의심되는 부분이 있다. 아래 사항을 체크해보자. 1. nginx의 설정 파일에서 access_log off 로 해둔 것은 아닌지 확인해보자. 2. 권한 이슈일 수 있다. nginx 의 worker process 가 로그 파일에 쓰기 권한이 있는지 확인해본다. nginx 설정에서 user 에 할당한 사용자가, access_log 파일이 있는 디렉토리와 파일에 쓰기 권한이 있는지 확인해보면 된다. 아래 명령으로 워커 프로세스의 사용자를 확인해보자. $ ps -eo "%U %G %a" | gr..
발생일: 2016.07.14 키워드: nginx, ssi, 중첩 if 문, multiple condition, server side include 문제: nginx 의 SSI에서 중첩으로 if 구문을 넣으려고 한다. 아래처럼 넣어봤는데 잘 되지 않는다. ... 이상하다. 아래처럼 && 연산자로 추가해봤는데도 잘 되지 않는다. ... 여러 방법으로 테스트해봤는데, 어떤 경우엔 [an error occurred while processing the directive] 와 같이 구문 오류라고 나오고, 어떤 경우엔 바깐 if 문을 타는 등 의도치 않게 동작한다. 왜 그럴까? 해결책: nginx SSI 모듈 API에 따르면 if 구문은 1뎁스만 가능하다고 한다. > Only one level of nesting ..
발생일: 2015.12.31 키워드: nginx, 413 문제: nginx 에서 413 코드에 아래와 같은 응답을 내려준다. 413 Request Entity Too Large 해결책: 말 그대로 요청 사이즈가 너무 커서 nginx 에서 잘라버린 요청이다. 더 허용해도 괜찮다면 nginx.conf 파일에서 요청 바디의 최대 사이즈를 정의해주면 된다. client_max_body_size 16M; 논의: nginx의 설정을 변경한 후에도 Entity Too Large 오류가 난다면, 앱 서버의 설정 때문일 수 있다. node.js express 서버를 사용하고 있다면, bodyParser에서 limit을 설정할 수 있다. var bodyParser = require('body-parser');app.use..
발생일: 2015.07.20 키워드: nginx, 설정, 디렉티브, directive 문제: nginx 설정의 상속 모델에 대해 잘 설명한 포스트가 있어 요약해봤다. 해결책: nginx에서는 아래 6개의 컨텍스트가 존재한다. - Global. - Http. - Server. - If. - Location. - Nested Location. - If in location. - limit_except. 기본 상속 모델은 부모 블럭에서 자식 블럭으로 상속받는 순이다. 형제 블럭이나 부모 블럭으로 전달되는 경우는 없다. nginx에서 상속이 동작하는 방식은 아래 4개의 타입으로 구분할 수 있다. - Normal directive 컨텍스트 당 한 개의 값 (예: root, index) - Array directi..
발생일: 2015.02.25 키워드: nginx, 엔진엑스, proxy_pass, ssl 문제: nginx로 리버스 프록시를 구성할 때, upstream 디렉티브에서 https 서버를 사용해 설정하고 싶다. 해결책: upstream 으로 정의할 때, 포트를 정의해주면 된다. 리버스 프록시를 호출할 때엔 https 로 정의한다. upstream example_api { server example.com:443; } location … { proxy_pass https://example_api; }
발생일: 2014.04.14 키워드: nginx, 웹 폰트, web font, mime type, 마임 타입 문제: 서버에 웹 폰트 리소스를 올려두고 서빙하려고 하는데, nginx 가 제대로 응답하지 못해 웹 폰트가 적용되지 않는다. 해결책: nginx 의 기본 마임 타입에 웹 폰트 리소스의 타입이 포함되어 있지 않기 때문이다. nginx의 conf/mime.types 파일에 아래 타입을 추가해주면 된다. font/ttf ttf; font/opentype otf; application/font-woff woff; application/vnd.ms-fontobject eot; - 기본 타입에 `eot` 확장자는 `application/octet-stream`으로 정의되어 있는데, 이 라인은 삭제해준다. -..