웹사이트 검색

가상 사설 서버에서 Nginx 웹 서버를 구성하는 방법

상태: 더 이상 사용되지 않음

이 문서에서는 더 이상 지원되지 않는 Ubuntu 버전에 대해 설명합니다. 현재 Ubuntu 12.04를 실행하는 서버를 운영 중인 경우 지원되는 Ubuntu 버전으로 업그레이드하거나 마이그레이션하는 것이 좋습니다.

  • Ubuntu 14.04로 업그레이드합니다.
  • Ubuntu 14.04에서 Ubuntu 16.04로 업그레이드
  • 서버 데이터를 지원되는 버전으로 마이그레이션

이유:

대신 참조:

엔진엑스란?

Nginx는 웹 서버이자 리버스 프록시 서버입니다. 널리 채택되어 다른 많은 일반적인 옵션을 대체하고 있습니다.

Nginx는 강력한 도구이지만 다른 서버에서 온 사용자나 일반적으로 웹 서버를 처음 사용하는 사용자에게는 구성이 어려울 수 있습니다. 이 가이드에서는 기본 Nginx 구성 파일을 탐색하고 일부 구문과 옵션을 설명합니다.

Ubuntu 12.04 설치를 사용하지만 대부분의 배포는 비슷한 파일 위치로 구성됩니다.

Nginx 구성 디렉토리 계층

Nginx는 구성 파일을 "/etc/nginx" 디렉토리에 저장합니다.

이 디렉토리 안에는 몇 개의 디렉토리와 다양한 모듈식 구성 파일이 있습니다.

cd /etc/nginx
ls -F
conf.d/         koi-win           naxsi.rules   scgi_params       uwsgi_params
fastcgi_params  mime.types        nginx.conf    sites-available/  win-utf
koi-utf         naxsi_core.rules  proxy_params  sites-enabled/

Apache에서 온 경우 "sites-available" 및 "sites-enabled" 디렉토리가 익숙할 것입니다.

이 디렉토리는 웹 사이트에 대한 구성을 정의하는 데 사용됩니다. 파일은 일반적으로 "sites-available" 디렉토리에 생성된 다음 라이브로 갈 준비가 되면 "sites-enabled" 디렉토리에 기호로 연결됩니다.

"conf.d" 디렉토리는 사이트 구성에도 사용할 수 있습니다. ".conf"로 끝나는 이 디렉토리 내의 모든 파일은 Nginx가 시작될 때 구성으로 읽히므로 모든 파일이 유효한 Nginx 구성 구문을 정의하는지 확인하십시오.

"/etc/nginx" 디렉토리에 있는 대부분의 다른 파일에는 특정 프로세스 또는 선택적 구성 요소의 구성 세부 정보가 포함되어 있습니다.

그러나 \nginx.conf\ 파일이 기본 구성 파일입니다. 이 파일을 더 자세히 살펴보겠습니다.

nginx.conf 파일 탐색

nginx.conf 파일은 Nginx의 주요 제어 지점입니다. 이 파일은 다른 모든 적절한 구성 파일을 읽고 서버가 시작될 때 모놀리식 구성 파일로 결합합니다.

일반적인 형식에 대해 논의할 수 있도록 파일을 엽니다.

sudo nano /etc/nginx/nginx.conf
user www-data;
worker_processes 4;
pid /var/run/nginx.pid;

events {
        worker_connections 768;
        # multi_accept on;
}

http {
. . .

처음 몇 줄은 Nginx가 작동하는 방식에 대한 몇 가지 일반적인 사실을 정의하는 데 사용됩니다.

예를 들어, 서버는 "user www-data" 줄에 의해 실행할 사용자를 결정합니다. Ubuntu의 일반적인 웹 서버 사용자입니다.

"pid" 지시문은 내부 참조를 위해 프로세스 pid가 저장되는 위치를 지정합니다. "worker_processes"는 Nginx가 사용할 동시 프로세스 수를 정의합니다.

구성 파일의 이 부분에는 "error_log" 지시문을 사용하는 오류 로그 위치와 같은 항목도 포함될 수 있습니다.

파일의 다음 섹션은 이벤트 섹션입니다. 이것은 Nginx가 연결을 처리하는 방법을 제어하는 특별한 위치입니다. 이 예에서는 이 섹션에서 아무것도 조정할 필요가 없으므로 계속 진행하겠습니다.

다음 섹션은 http 블록입니다. 이것은 Nginx 구성 파일의 형식에 대한 보다 복잡한 논의로 이어집니다.

Nginx 구성 파일 레이아웃

Nginx 구성 파일은 \blocks\에서 관리됩니다.

우리가 본 첫 번째 블록은 이벤트 블록이었습니다. 다음은 http 블록이며 구성 파일 내 기본 계층의 시작입니다.

http 블록 내의 구성 세부 정보는 계층화되어 있으며 동봉된 블록은 해당 블록의 속성을 상속합니다. 대부분의 Nginxs 일반 구성은 서버 블록이 있는 http 블록에서 이루어지며 여기에는 위치 블록이 포함됩니다.

중요한 부분은 구성 세부 정보가 적용되는 가장 높은 컨테이너에 항상 구성 세부 정보를 입력해야 한다는 것입니다. 즉, 매개변수 X를 모든 서버 블록에 적용하려는 경우 http 블록 내에 배치하면 모든 서버 구성에 전파됩니다.

우리 파일을 보면 소프트웨어가 전체적으로 어떻게 작동해야 하는지를 지시하는 많은 옵션이 있음을 알 수 있습니다. 이것은 이러한 종류의 지시문에 대한 적절한 위치입니다.

예를 들어 다음 줄로 설정된 파일 압축 옵션이 있습니다.

gzip on;
gzip_disable "msie6";

이것은 Nginx에게 클라이언트로 전송되는 데이터를 압축하기 위해 gzip을 활성화하도록 지시하지만, 클라이언트가 Internet Explorer 버전 6인 경우 해당 브라우저가 gzip 압축을 이해하지 못하기 때문에 gzip 압축을 비활성화하도록 지시합니다.

일부 서버 블록에 대해 다른 값을 가져야 하는 옵션이 있는 경우 더 높은 수준에서 지정한 다음 서버 블록 내에서 재정의할 수 있습니다. Nginx는 설정에 적용되는 가장 낮은 수준의 사양을 사용합니다.

가능한 가장 높은 수준에서 설정을 적용하는 이 스타일을 사용하면 여러 개의 동일한 선언을 관리할 필요가 없습니다. 또한 "server" 블록 수준 이하에서 무언가를 선언하는 것을 잊은 경우에 사용할 수 있는 기본값을 제공하는 이점이 있습니다.

\nginx.conf\ 파일에서 \http\ 블록의 끝이 다음과 같은 것을 볼 수 있습니다:

include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;

이는 특정 사이트 및 URL 일치 위치를 정의하는 서버 및 위치 블록이 이 파일 외부에서 발생함을 알려줍니다.

이를 통해 새 사이트를 제공하고자 할 때 새 파일을 생성할 수 있는 모듈식 구성 배열을 유지할 수 있습니다. 대부분의 상황에서 변경되지 않는 세부 정보를 숨기면서 관련 콘텐츠를 함께 그룹화할 수 있습니다.

다음 섹션에서 개별 사이트 구성을 검사할 수 있도록 "nginx.conf" 파일을 종료합니다.

기본 서버 블록 탐색

Nginx는 서버 블록을 사용하여 Apache의 가상 호스트에 있는 기능을 수행합니다. 서버 블록을 서버가 호스팅할 수 있는 개별 웹 사이트에 대한 사양으로 생각하십시오.

"sites-available" 디렉토리에 포함된 기본 서버 블록 구성을 살펴보겠습니다. 이 파일에는 기본 웹 페이지를 제공하는 데 필요한 모든 필수 정보가 들어 있습니다.

cd sites-available
sudo nano default
server {
	root /usr/share/nginx/www;
	index index.html index.htm;

	server_name localhost;

	location / {
		try_files $uri $uri/ /index.html;
	}

	location /doc/ {
		alias /usr/share/doc/;
		autoindex on;
		allow 127.0.0.1;
		deny all;
	}
}

기본 파일에는 주석이 잘 달려 있지만 공간을 절약하고 사이트 정의가 얼마나 간단한지 보여주기 위해 여기에서 주석을 제거했습니다.

여는 괄호와 연결된 닫는 괄호 사이의 모든 것을 포함하는 서버 블록이 있습니다.

server {
	. . .
}

이 블록은 지난 섹션에서 설명한 것처럼 "include" 지시문을 사용하여 http 블록의 끝 부분에 있는 "nginx.conf" 파일에 배치됩니다.

"root" 지시어는 웹사이트 콘텐츠가 있는 디렉토리를 정의합니다. 이것은 Nginx가 브라우저에서 요청한 파일을 찾기 시작하는 위치입니다. 기본 웹사이트는 "/usr/share/nginx/www"에서 콘텐츠를 검색합니다.

각 줄이 어떻게 세미콜론(;)으로 끝나는지 확인하십시오. 이것은 Nginx가 하나의 디렉티브가 완료되고 다음 디렉티브가 시작될 것임을 아는 방법입니다. 세미콜론을 잊지 마십시오. 그렇지 않으면 Nginx가 지시문에 대한 추가 인수로 뒤따르는 행을 처리합니다. 세미콜론에 도달할 때까지 이 작업을 수행합니다.

다음 줄은 \index\ 지시문과 관련이 있습니다.

도메인에 제공되는 기본 페이지를 구성합니다. 페이지가 요청되지 않은 경우 서버 블록은 "index.html"이라는 파일을 검색하여 반환합니다. 해당 파일을 찾을 수 없으면 "index.htm"이라는 파일을 제공하려고 시도합니다.

server_name 지시문 사용

"server_name" 지시문에는 이 서버 블록에서 제공될 도메인 이름 목록이 포함되어 있습니다. 공백으로 구분하여 원하는 만큼 많은 이름을 포함할 수 있습니다.

모든 항목과 일치하는 와일드카드로 서버 이름의 시작 또는 끝에 있는 별표 문자를 사용할 수도 있습니다. 예를 들어 "*.example.com"은 "forum.example.com" 및 "animals.example.com"에 대한 요청과 일치합니다.

요청된 URL이 둘 이상의 "server_name" 지시문과 일치하는 경우 정확히 일치하는 항목을 먼저 선택합니다. 정확히 일치하는 항목이 없으면 별표로 시작하는 가장 긴 와일드카드 이름을 선택합니다.

여전히 일치하는 항목을 찾지 못한 경우 별표로 끝나는 가장 긴 일치 와일드카드 이름을 찾습니다. 이들 중 아무것도 발견되지 않으면 일치하는 첫 번째 정규식 일치를 반환합니다.

일치시키기 위해 정규식을 사용하는 서버 이름은 물결표(~) 문자로 시작합니다. 정규식은 매우 강력하지만 이 기사의 범위를 벗어납니다.

위치 블록 사용

구성 파일의 다음 부분은 위치 블록을 엽니다. 위치 블록은 서버 내에서 특정 리소스 요청을 처리하는 방법을 지정하는 데 사용됩니다.

"location /" 줄은 대괄호 안의 지시문이 다른 위치 블록과 일치하지 않는 클라이언트가 요청한 모든 리소스에 적용됨을 지정합니다.

위치 블록은 파일 아래쪽에 지정된 "/doc/" 경로와 같은 uri 경로를 포함할 수 있으며 위치와 uri 사이에 등호(=)를 사용하여 정확히 일치하도록 지정하거나 물결표(~) 문자를 사용하여 정규식 일치를 나타냅니다.

일반 물결표는 대소문자를 구분하는 일치를 나타내고, 별표(~*) 뒤에 오는 물결표는 대소문자를 구분하지 않는 일치를 의미하며, 앞에 캐럿(^~)이 오는 물결표는 uri가 이 위치와 일치하는 경우 정규식 검색을 수행하지 않도록 Nginx에 지시합니다.

Nginx에는 사용할 블록을 결정하는 잘 정의된 프로세스가 있다는 점에서 위치 일치는 server_name 일치와 유사합니다.

쿼리가 등호가 있는 위치와 일치하면 해당 위치가 사용되고 검색이 중지됩니다. 그렇지 않은 경우 일반 리터럴 URI 위치가 검색됩니다. 캐럿 물결표(^~)가 사용되었고 uri 위치가 일치하면 이 블록이 선택됩니다.

해당 옵션을 사용하지 않으면 가장 구체적인 일치 항목을 선택하고 값을 유지합니다. 그런 다음 정규식 일치를 수행하여 해당 패턴과 일치할 수 있는지 확인합니다. 발견되면 정규식 블록이 사용됩니다. 그렇지 않으면 이전에 일치된 uri 위치가 사용됩니다.

요약하면 Nginx는 정확한 일치, 정규식 일치, 리터럴 URI 일치 순으로 선호하지만 리터럴 URI 일치는 앞에 "^~"를 붙여 명시적으로 더 중요하게 만들 수 있습니다.

이 목록은 다음 기본 설정을 정의합니다.

<ol>
	<li>Equal sign matches</li>
	<li>Literal URI matches with "^~"</li>
	<li>Most specific regular expression match</li>
	<li>Most specific literal URI match</li>
</ol>

혼란스러워 보일 수 있지만 이러한 정의된 규칙은 Nginx가 모호함 없이 결정을 내릴 수 있도록 필요합니다.

try_file 사용 방법

try_files 지시문은 리소스 요청에 대해 시도해야 하는 일련의 시도를 정의하는 데 매우 유용한 도구입니다.

이것이 의미하는 바는 Nginx가 일련의 대체 옵션을 통해 요청을 처리하는 방법을 선언할 수 있다는 것입니다.

기본 구성 파일의 예는 다음과 같습니다.

try_files $uri $uri/ /index.html;

즉, 해당 위치 블록에서 제공되는 요청이 있을 때 Nginx는 먼저 리터럴 URI를 파일로 제공하려고 시도합니다. 이는 요청 중인 리소스를 보유할 "$uri" 변수를 사용하여 선언됩니다.

$uri 값과 일치하는 파일이 없으면 uri를 디렉토리로 사용하려고 시도합니다. uri 디렉토리에 대한 기본 파일(기억한다면 index.html)을 제공하려고 시도할 것입니다.

$uri 값과 일치하는 디렉토리가 없으면 서버 블록 루트 디렉토리의 "index.html" 파일인 기본 파일을 사용합니다. 각 "try_files" 지시문은 마지막 매개변수를 폴백 기본값으로 사용하므로 알려진 실제 파일이어야 합니다.

앞의 매개변수가 일치하지 않는 경우 파일을 반환하지 않으려는 경우 다른 옵션은 오류 페이지를 반환하는 것입니다. 이는 등호와 오류 코드를 사용하여 수행됩니다.

예를 들어 기본 "index.html" 페이지를 제공하는 대신 리소스를 찾을 수 없는 경우 "location /" 블록이 404 오류를 반환하도록 하려면 마지막 파일을 "=로 바꿀 수 있습니다. 404\:

try_files $uri $uri/ =404;

존재하지 않는 리소스를 요청하는 경우 사용자에게 적절한 오류 페이지가 표시됩니다.

추가 옵션

구성 파일의 나머지 부분에는 몇 가지 다른 흥미로운 지시문이 포함되어 있습니다.

"alias" 지시어는 Nginx에게 해당 위치 블록에 대한 페이지가 지정된 디렉토리에서 제공되어야 한다고 알려줍니다. 이들은 루트 디렉토리 외부에 있을 수 있습니다.

이 예에서 \/doc/\ 내에서 요청된 리소스는 \/usr/share/doc/\에서 제공됩니다.

"autoindex on" 지시문을 사용하면 Nginx가 지정된 위치에 대한 디렉토리 목록을 생성할 수 있습니다. 디렉터리가 요청되면 반환됩니다.

"allow" 및 "deny" 줄은 디렉토리에 대한 액세스 제어를 설정합니다. 우리 파일의 줄은 사용자가 로컬 서버에서 위치에 액세스하려고 할 때 내용을 읽을 수 있도록 합니다.

결론

Nginx는 일부 기능에 대해 다른 용어를 사용하지만 구성 옵션이 많은 매우 유능한 서버입니다.

Nginx 웹 서버를 올바르게 구성하는 방법을 배우면 매우 강력하면서도 리소스가 매우 적은 소프트웨어를 최대한 활용할 수 있습니다. 이것은 모든 규모의 웹 사이트에 이상적인 선택입니다.