Nginx 서버 블록(가상 호스트)으로 여러 웹사이트 호스팅하기

Nginx 서버 블록은 단일 Nginx 설치로 여러 도메인 또는 웹사이트를 별도의 구성으로 호스팅할 수 있게 해주는 가상 호스트 개념입니다. 예를 들어, 동일한 VPS에서 example.com, blog.example.com 및 second-site.com에 대해 각각 다른 루트 디렉터리, 로그 파일, SSL 인증서 및 PHP 설정을 정의할 수 있습니다. 요약하자면, 각 사이트에 대해 별도의 디렉터리를 만들고, 도메인의 DNS 기록을 서버 IP 주소로 리디렉션하며, /etc/nginx/sites-available 아래에 별도의 서버 블록을 작성하고 이를 sites-enabled 디렉터리에 연결한 후, 구성을 테스트하고 Nginx 서비스를 다시 로드하는 것입니다.

이 가이드에서는 Nginx 서버 블록을 사용하여 여러 웹사이트를 호스팅하는 과정을 생산 환경에 적합하게 다룰 것입니다. 목표는 단순히 작동하는 구조를 만드는 것이 아니라, 관리 가능하고, 안전하며, 빠르고, 백업 가능하고, 확장 가능한 환경을 만드는 것입니다. 특히 에이전시, 개발자, 전자상거래 소유자, 다중 브랜드를 운영하는 비즈니스 및 단일 서버에서 여러 프로젝트를 운영하는 시스템 관리자들을 위해 실용적인 단계를 공유할 것입니다. 아직 서버가 없다면 리소스 선택을 위한 VPS 서버와 도메인 관리에 대한 도메인 등록 페이지를 확인해 보세요.

Nginx 서버 블록이란?

Nginx 서버 블록은 Nginx 구성 내에서 server 블록으로 정의되며, 들어오는 HTTP 또는 HTTPS 요청이 어떤 사이트로 리디렉션될지를 결정하는 구성 요소입니다. Apache의 VirtualHost 개념과 유사합니다. 방문자가 브라우저에 도메인을 입력하면 DNS는 해당 도메인을 서버의 IP 주소로 해석합니다. 이후 Nginx는 요청의 Host 헤더를 확인하고 server_name 값이 일치하는 서버 블록을 실행합니다.

이를 통해 동일한 IP 주소와 동일한 물리적 또는 가상 서버에서 수십 개의 다양한 웹사이트를 호스팅할 수 있습니다. 각 사이트에 대해 별도의 루트 디렉터리, 액세스 로그, 오류 로그, 리디렉션 규칙, SSL 인증서, 캐시 정책 및 보안 규칙을 정의하는 것이 가능합니다. 예를 들어, 기업 사이트는 /var/www/kurumsal/public에, 블로그는 /var/www/blog/public에, 테스트 환경은 /var/www/staging/public에 보관할 수 있습니다.

Nginx는 이러한 구조에서 매우 효율적입니다. 이벤트 중심 아키텍처 덕분에 높은 동시 연결을 낮은 자원 소비로 관리할 수 있습니다. 따라서 공유 호스팅, VPS, 클라우드 서버 및 고트래픽 애플리케이션 인프라에서 자주 선호됩니다. 다중 사이트 호스팅이 원활하게 작동하기 위해서는 파일 권한, DNS 리디렉션, SSL 설치, 로그 분리 등 모든 세부 사항이 정확하게 계획되어야 합니다.

Nginx 서버 블록은 언제 사용하나요?

Nginx 서버 블록은 특히 단일 서버에서 여러 웹 자산을 관리해야 할 때 사용됩니다. 이는 때때로 두 개의 작은 기업 사이트일 수도 있고, 수십 개의 고객 프로젝트, 서브도메인 또는 마이크로 서비스일 수도 있습니다. 여기서 중요한 점은 각 프로젝트가 논리적으로 서로 분리되어야 한다는 것입니다.

• 여러 도메인을 동일한 VPS에서 호스팅하고 싶을 때.
• www와 www 없는 도메인을 하나의 정규 주소로 리디렉션하려고 할 때.
• 서브도메인을 다른 폴더나 애플리케이션에 연결하려고 할 때.
• 각 사이트에 대해 별도의 SSL 인증서 및 보안 정책을 정의하고 싶을 때.
• 고객 프로젝트를 별도의 로그 파일로 추적하고 싶을 때.
• Laravel, WordPress, 정적 HTML 및 Node.js와 같은 다양한 애플리케이션을 동일한 서버에서 실행하고 싶을 때.

예를 들어, 디지털 에이전시가 단일 4GB RAM VPS에서 8개의 저트래픽 기업 사이트를 호스팅하는 것이 기술적으로 가능합니다. 하지만 각 사이트의 트래픽, 디스크 사용량, PHP 프로세스 수, 데이터베이스 부하 및 백업 빈도를 계산해야 합니다. 프로젝트가 높은 트래픽을 받거나 자원 격리가 중요하다면 더 강력한 VPS, 클라우드 서버 또는 관리형 호스팅 솔루션을 선택해야 합니다. 이 시점에서 웹 호스팅과 기업 호스팅 옵션을 비교할 수 있습니다.

시작하기 전에 요구 사항

이 가이드에서는 Ubuntu 또는 Debian 기반의 Linux 서버를 가정합니다. 명령어는 배포에 따라 약간의 차이를 보일 수 있지만, 논리는 동일합니다. 생산 환경에서 작업을 수행하기 전에 반드시 백업을 진행하세요. 잘못된 Nginx 구성으로 인해 모든 사이트가 일시적으로 접근 불가능할 수 있습니다.

필수 기술 준비 사항

• Root 또는 sudo 권한이 있는 Linux 사용자 계정.
• 설치되고 실행 중인 Nginx 서비스.
• 서버 IP 주소로 리디렉션된 최소한 하나의 도메인.
• 80 및 443 포트가 방화벽에서 열려 있어야 합니다.
• 사이트 파일을 위한 정리된 디렉터리 구조.
• SSL을 위한 유효한 인증서 또는 무료 Let’s Encrypt 사용.
• PHP 기반 애플리케이션을 위한 PHP-FPM 설치.

DNS 측면에서 A 레코드는 기본 도메인을 IPv4 주소로, AAAA 레코드가 있다면 IPv6 주소로 리디렉션합니다. www와 같은 서브도메인에 대해서는 CNAME 또는 A 레코드를 사용할 수 있습니다. DNS 전파는 일반적으로 몇 분에서 24시간 내에 완료됩니다. 새 설치를 진행할 때는 먼저 DNS 기록을 준비한 후 Nginx 서버 블록 구성을 진행하는 것이 프로세스를 빠르게 합니다.

권장 디렉터리 구조

여러 사이트를 호스팅할 때 가장 흔히 발생하는 실수 중 하나는 모든 파일을 혼란스럽게 하나의 디렉터리에 보관하는 것입니다. 이 접근 방식은 단기적으로는 간편해 보일 수 있지만, 유지 관리, 백업 및 오류 디버깅 과정에서 상당한 시간을 낭비하게 됩니다. 더 나은 방법은 각 도메인에 대해 별도의 상위 디렉터리를 만들고 그 안에 public, logs, backups와 같은 하위 디렉터리를 사용하는 것입니다.

예시 구조는 다음과 같이 계획할 수 있습니다: /var/www/site1.com/public, /var/www/site1.com/logs, /var/www/site2.com/public 및 /var/www/site2.com/logs. Nginx의 root 값은 직접 public 디렉터리를 가리켜야 합니다. 이렇게 하면 애플리케이션 파일, .env와 같은 민감한 파일 및 백업이 웹을 통해 직접 접근할 수 없게 됩니다.

정적 테스트 페이지의 경우 각 사이트 폴더에 간단한 index.html 파일을 넣어 사이트 이름을 작성하여 어떤 서버 블록이 작동하는지 빠르게 확인할 수 있습니다. 생산 환경에서는 이러한 폴더의 소유자는 일반적으로 www-data 사용자 또는 배포를 수행하는 전용 사용자로 설정됩니다. 파일 권한에서 폴더는 755, 파일은 644가 대부분의 정적 시나리오에서 충분합니다. WordPress와 같이 쓰기 권한이 필요한 애플리케이션에서는 uploads 디렉터리와 같은 영역을 추가로 고려해야 합니다.

단계별 Nginx 서버 블록 생성

아래 단계는 site1.com 도메인을 기준으로 설명합니다. 동일한 방법을 두 번째, 세 번째 또는 그 이상의 사이트에도 반복할 수 있습니다. 중요한 점은 각 사이트에 대해 고유한 server_name, root 및 로그 파일을 사용하는 것입니다.

1. 사이트 폴더 만들기

첫 번째 단계는 웹 파일이 저장될 디렉터리를 만드는 것입니다. 예: sudo mkdir -p /var/www/site1.com/public. 그런 다음 테스트를 위해 /var/www/site1.com/public/index.html 파일을 생성하고 그 안에 이 사이트는 site1.com 테스트 페이지입니다와 같은 식별 가능한 텍스트를 작성할 수 있습니다.

파일 소유권을 올바르게 설정하기 위해 sudo chown -R www-data:www-data /var/www/site1.com 명령어를 사용할 수 있습니다. 만약 다른 사용자로 배포 작업을 수행하고 있다면 그룹 권한을 이에 따라 조정해야 합니다. 생산 환경에서는 모든 사람이 쓰기 권한을 가질 수 있는 777 권한을 피해야 합니다. 이러한 권한은 공격자가 업로드 디렉터리를 악용할 수 있게 합니다.

2. 서버 블록 파일 만들기

Nginx에서 일반적인 관행은 비활성 구성을 /etc/nginx/sites-available에 보관하고 활성화할 파일을 /etc/nginx/sites-enabled로 심볼릭 링크로 연결하는 것입니다. 예시 파일: /etc/nginx/sites-available/site1.com.

단순한 HTTP 서버 블록은 다음과 같은 논리로 작성됩니다: server { listen 80; server_name site1.com www.site1.com; root /var/www/site1.com/public; index index.html index.htm; access_log /var/log/nginx/site1.com.access.log; error_log /var/log/nginx/site1.com.error.log; location / { try_files $uri $uri/ =404; } }

이 구성에서 listen 80은 HTTP 트래픽을 수신하고, server_name은 어떤 도메인이 이 블록에 속하는지를 명시하며, root는 웹 파일이 있는 디렉터리를 나타냅니다. index는 기본 파일을 정의합니다. try_files는 요청된 파일이나 폴더를 찾지 못하면 404를 반환합니다. 정적 사이트의 경우 이 구조는 충분합니다.

3. 사이트 활성화하기

구성을 활성화하기 위해 심볼릭 링크를 생성합니다: sudo ln -s /etc/nginx/sites-available/site1.com /etc/nginx/sites-enabled/site1.com. 이 방법은 파일을 복사하는 것보다 더 건강하며, 단일 기본 구성 파일에서 작업할 수 있습니다. 변경 사항을 적용할 때 연결된 파일도 최신 상태로 유지됩니다.

기본 Nginx 페이지가 귀하의 사이트 앞에 나타나지 않도록 하려면 기본 구성(default)을 비활성화할 수 있습니다. 이를 위해 /etc/nginx/sites-enabled/default 링크를 제거할 수 있습니다. 하지만 이를 수행하기 전에 귀하의 서버 블록이 올바르게 작동하는지 확인해야 합니다.

4. 구성 테스트 및 Nginx 다시 로드하기

모든 변경 후 sudo nginx -t 명령어로 구문 검사를 수행해야 합니다. 테스트가 성공적이라면 sudo systemctl reload nginx 명령어로 서비스를 중단 없이 다시 로드할 수 있습니다. reload 명령어는 일반적으로 restart 명령어보다 더 안전합니다. 왜냐하면 활성 연결을 더 부드럽게 관리하기 때문입니다.

테스트가 실패하면 오류 메시지는 대부분 파일 이름과 줄 번호를 나타냅니다. 누락된 세미콜론, 잘못된 중괄호, 잘못된 디렉터리 경로 또는 충돌하는 server_name 값이 가장 흔한 문제들입니다. 오류가 수정되지 않으면 Nginx를 다시 로드해서는 안 됩니다.

두 번째 및 세 번째 사이트 추가하기

여러 사이트를 호스팅하는 아름다움은 첫 번째 올바른 설정 후 프로세스가 반복 가능하다는 것입니다. site2.com에 대해 /var/www/site2.com/public 디렉터리를 만들고, /etc/nginx/sites-available/site2.com 파일을 작성하고, root 및 로그 값을 site2.com으로 변경하고, 심볼릭 링크를 생성한 후 Nginx 테스트를 수행합니다.

두 번째 사이트에 대한 단순한 구조는 다음과 같이 나뉩니다: server { listen 80; server_name site2.com www.site2.com; root /var/www/site2.com/public; index index.html; access_log /var/log/nginx/site2.com.access.log; error_log /var/log/nginx/site2.com.error.log; location / { try_files $uri $uri/ =404; } }

각 사이트마다 별도의 로그를 사용하는 것은 현실에서 매우 가치가 있습니다. 예를 들어, 한 사이트에서 404 오류가 증가할 때 다른 사이트에서는 문제가 없을 수 있습니다. 별도의 로그 구조 덕분에 오류의 원인을 몇 초 안에 찾을 수 있습니다. 마찬가지로 트래픽 분석, 봇 공격, 깨진 링크 및 성능 문제도 사이트별로 모니터링할 수 있습니다.

SSL 및 HTTPS 구성

2026 SEO 표준에서 HTTPS는 이제 단순한 보안 기능이 아니라 사용자 신뢰 및 기술 품질의 지표입니다. 브라우저는 HTTP 사이트를 안전하지 않은 것으로 표시하며, 결제, 회원가입, 양식 또는 관리 패널이 포함된 프로젝트에서는 SSL이 필수입니다. 여러 사이트를 호스팅할 때는 각 도메인에 대해 올바른 인증서를 정의해야 합니다. Hostragons을 통해 SSL 필요에 대한 SSL 인증서 페이지를 확인할 수 있습니다.

Let’s Encrypt를 사용하는 경우 Certbot을 통해 각 도메인에 대한 인증서를 받을 수 있습니다. 예시 프로세스에서 certbot --nginx -d site1.com -d www.site1.com 명령어는 Nginx 구성을 인식하고 HTTPS 블록을 자동으로 추가할 수 있습니다. 하지만 자동 편집 후 파일을 검토하는 것은 좋은 습관입니다. 잘못된 리디렉션이나 반복되는 서버 블록 문제가 발생할 수 있습니다.

HTTPS 구성에서는 일반적으로 80 포트의 트래픽이 443 포트로 영구적으로 리디렉션됩니다. 301 리디렉션은 SEO 관점에서 영구적인 선호 신호를 제공합니다. www 사용 여부를 결정하고 모든 변형을 하나의 정규 주소로 모아야 합니다. 예를 들어, https://www.site1.com 대신 https://site1.com을 사용할 경우, HTTP 및 HTTPS www 트래픽을 www 없는 주소로 리디렉션합니다. 이는 중복 콘텐츠 위험을 줄입니다.

PHP 및 WordPress 사이트를 위한 Nginx 서버 블록

정적 HTML 사이트에서는 구성이 간단하지만, WordPress, Laravel 또는 맞춤형 PHP 애플리케이션의 경우 PHP-FPM과의 통합이 필요합니다. 이 경우 index.php 파일이 정의되며 PHP 요청은 관련 소켓으로 리디렉션됩니다. 예를 들어, Ubuntu에서 PHP 8.3의 소켓 경로는 /run/php/php8.3-fpm.sock일 수 있습니다. 버전은 서버에 따라 다릅니다.

PHP 기반의 예시 구조: server { listen 80; server_name wordpress-site.com www.wordpress-site.com; root /var/www/wordpress-site.com/public; index index.php index.html; location / { try_files $uri $uri/ /index.php?$args; } location ~ php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php8.3-fpm.sock; } }

WordPress에서 영구 링크가 작동하려면 try_files $uri $uri/ /index.php?$args 구조가 중요합니다. 또한 xmlrpc.php 접근, wp-login.php 비율 제한, uploads 디렉터리에서 PHP 실행 방지와 같은 보안 조치를 고려해야 합니다. 동일한 VPS에서 여러 WordPress 사이트를 호스팅하는 경우 각 사이트에 대해 별도의 데이터베이스, 별도의 사용자 및 정기적인 업데이트 정책을 사용하세요. WordPress 호스팅 대안을 찾고 있다면 WordPress 호스팅이 더 관리 가능한 옵션일 수 있습니다.

Nginx 서버 블록과 Apache VirtualHost 비교

Nginx와 Apache는 동일한 목표를 다르 은 아키텍처로 달성합니다. 두 서버 모두 단일 서버에서 여러 사이트를 호스팅할 수 있습니다. 선택은 애플리케이션 요구 사항, 관리 습관 및 성능 기대에 따라 달라집니다.

애플리케이션이 .htaccess 규칙에 많이 의존하는 경우 Apache가 더 쉬울 수 있습니다. 그러나 높은 트래픽, 리버스 프록시, 캐시 및 현대 배포 흐름의 경우 Nginx가 대부분의 프로젝트에서 강력한 선택입니다. 일부 인프라에서는 Nginx가 리버스 프록시로, Apache가 백엔드 애플리케이션 서버로 함께 사용될 수 있습니다.

보안을 위한 모범 사례

여러 사이트를 동일한 서버에서 호스팅하는 것은 비용적 이점이 있지만 보안 책임을 증가시킵니다. 한 사이트의 취약점이 다른 사이트에 영향을 미치지 않도록 격리 및 최소 권한 원칙을 적용해야 합니다.

• 각 사이트에 대해 별도의 데이터베이스 및 별도의 데이터베이스 사용자 생성.
• 웹 루트 디렉터리를 오직 public 폴더로 제한.
• 백업, .env, .git, config 및 SQL 파일을 웹 접근에서 제외.
• SSL 인증서를 정기적으로 갱신하고 HTTPS 리디렉션을 의무화.
• 서버에 UFW 또는 유사한 방화벽을 사용하고, 필요한 포트만 열어 두세요.
• Nginx 및 운영 체제 업데이트를 정기적으로 수행하세요.
• 각 사이트에 대해 별도의 access_log 및 error_log 유지.
• 관리 패널에 IP 제한 또는 추가 인증 추가.
• 파일 권한에서 777과 같은 광범위한 권한을 피하세요.

또한 기본 보안 헤더를 추가하는 것이 유익합니다. X-Frame-Options, X-Content-Type-Options, Referrer-Policy 및 Content-Security-Policy와 같은 헤더는 적절한 프로젝트에서 고려될 수 있습니다. 그러나 특히 Content-Security-Policy를 잘못 적용하면 스크립트 및 스타일 파일을 차단할 수 있으므로 먼저 테스트 환경에서 시도해보아야 합니다. 보안에 관한 추가 콘텐츠는 웹사이트 보안 글에 링크될 수 있습니다.

성능 및 SEO를 위한 주의 사항

Nginx 서버 블록은 단순한 호스팅 외에도 성능 및 SEO 품질에 영향을 미칩니다. 잘못된 리디렉션 체인, 잘못된 정규화 선택, 누락된 gzip 또는 brotli 압축, 큰 로그 파일 및 불충분한 캐시 설정은 사이트 속도를 떨어뜨릴 수 있습니다. Google의 페이지 경험 신호는 사용자 중심이며, 빠르게 응답하고 안전하고 안정적인 사이트가 더 나은 성능을 보이는 경향이 있습니다.

우선 각 도메인에 대해 단일 정규 버전을 설정하세요. HTTP에서 HTTPS로, www에서 www 없는 주소로 또는 그 반대로 한 번에 리디렉션하세요. 체인은 다음과 같아서는 안 됩니다: http://site.com이 먼저 http://www.site.com으로, 그 다음 https://www.site.com으로, 그 다음 https://site.com으로 리디렉션됩니다. 대신 단일 301로 목표로 가는 것이 더 바람직합니다.

정적 파일에 대해서는 cache-control 헤더를 사용할 수 있습니다. 이미지, CSS 및 JS 파일은 일정 기간 동안 브라우저에 저장될 수 있습니다. 그러나 자주 변경되는 파일에서는 파일 이름 버전 관리 또는 쿼리 문자열 전략을 사용해야 합니다. gzip 압축은 HTML, CSS, JS 및 JSON과 같은 텍스트 기반 파일의 대역폭을 줄입니다. 높은 트래픽을 받는 사이트에서는 Nginx microcache, FastCGI 캐시 또는 CDN 사용을 고려할 수 있습니다. CDN 및 글로벌 접근 필요성에 대해서는 CDN이란?와 같은 콘텐츠에 링크될 수 있습니다.

로그 관리 및 모니터링

여러 사이트를 호스팅하는 데 있어 로그 관리는 문제 해결의 열쇠입니다. 별도의 로그 파일은 어떤 사이트에서 어떤 오류가 발생했는지를 명확하게 보여줍니다. access_log는 방문자 요청을 기록하고, error_log는 구성, 권한, 파일 부재 및 업스트림 오류를 기록합니다. 502 Bad Gateway 오류는 일반적으로 PHP-FPM 또는 백엔드 서비스 연결과 관련이 있습니다. 403 Forbidden은 권한 또는 인덱스 파일 문제일 수 있습니다. 404 Not Found는 파일 경로, 리라이트 또는 DNS 이후 잘못된 루트 문제를 나타낼 수 있습니다.

로그 파일의 무한 증식을 방지하기 위해 logrotate 구성을 점검해야 합니다. 작은 프로젝트에서는 일일 또는 주간 회전이 충분할 수 있습니다. 트래픽이 높은 사이트에서는 중앙 로그 수집, 메트릭 모니터링 및 알림 시스템을 사용해야 합니다. 디스크가 가득 차면 Nginx가 로그를 쓸 수 없게 되고, 데이터베이스가 중단되며, 사이트에 접근할 수 없게 될 수 있습니다. 따라서 디스크 사용량에 대한 임계값을 설정하는 것은 실용적인 예방 조치입니다.

일반적인 오류 및 빠른 해결책

Nginx 서버 블록과 작업할 때 몇 가지 오류는 거의 모든 프로젝트에서 발생할 수 있습니다. 이를 알고 있으면 설치 시간을 크게 단축할 수 있습니다.

• 틀린 사이트가 열리는 경우: server_name 충돌 및 기본 서버 블록을 확인하세요.
• 403 Forbidden 오류: 루트 디렉터리, 파일 권한 및 인덱스 파일의 존재를 확인하세요.
• 404 Not Found 오류: 루트 경로 및 try_files 규칙을 검토하세요.
• 502 Bad Gateway 오류: PHP-FPM 서비스가 작동하는지 및 소켓 경로가 올바른지 확인하세요.
• SSL 인증서가 잘못된 사이트에 속하는 경우: 443 포트의 server_name 및 인증서 파일을 확인하세요.
• 리디렉션 루프가 발생하는 경우: HTTP-HTTPS 및 www 리디렉션 규칙을 단순화하세요.
• Nginx reload가 되지 않는 경우: sudo nginx -t 출력의 줄 번호에 따라 구문 오류를 수정하세요.

경험이 풍부한 관리자들이 사용하는 간단한 체크리스트가 있습니다: DNS가 올바른지, Nginx 구성이 활성화되었는지, 루트 폴더가 존재하는지, 권한이 올바른지, 서비스가 테스트를 통과했는지, 로그가 무엇을 말하는지? 이 순서대로 진행하면 당황하지 않고 빠르게 문제를 해결할 수 있습니다.

생산 환경을 위한 실용적인 체크리스트

라이브로 전환하기 전에 아래 체크리스트로 각 사이트를 확인하세요. 특히 고객 프로젝트의 경우 인도 전에 이 항목들을 문서화하는 것은 전문적인 작업 표준을 생성합니다.

• 도메인 A 또는 AAAA 레코드가 올바른 IP 주소로 리디렉션되고 있습니다.
• www 및 www가 없는 버전 중 하나가 정규로 선택되었습니다.
• HTTP 트래픽이 HTTPS로 301로 리디렉션됩니다.
• SSL 인증서가 유효하고 자동 갱신이 활성화되었습니다.
• 각 사이트에 대해 별도의 루트 및 로그 파일이 정의되었습니다.
• Nginx 구성이 sudo nginx -t로 검증되었습니다.
• 백업 계획이 수립되었고 복원 테스트가 수행되었습니다.
• 파일 권한이 최소 권한 원칙에 따라 설정되었습니다.
• 방화벽에서 필요한 포트만 열려 있습니다.
• 오류 로그가 라이브 전환 후 최소 15분 동안 모니터링되었습니다.

이 체크리스트는 작아 보이지만 실제 프로젝트에서 중단 위험을 크게 줄입니다. 특히 SSL 갱신, DNS 확인 및 로그 모니터링 단계는 대부분의 보이지 않는 오류를 조기에 발견합니다.

결론

Nginx 서버 블록은 단일 서버에서 여러 사이트를 정리되고 안전하며 성능 있게 호스팅하는 기본 방법 중 하나입니다. 올바른 디렉터리 구조, 별도의 구성 파일, 명확한 리디렉션 규칙, HTTPS 사용, 로그 분리 및 정기적인 테스트 프로세스를 통해 다중 사이트 관리는 매우 효율적이 됩니다. 작은 포트폴리오 사이트에서 다수의 고객 프로젝트에 이르기까지 동일한 원칙을 적용할 수 있습니다.

새로운 프로젝트를 배포하려면 먼저 도메인, 서버 리소스 및 SSL 필요 사항을 명확히 하세요. 그런 다음 위의 체크리스트를 사용하여 Nginx 구성을 단계별로 설정하세요. 더 관리 가능한 인프라를 원하신다면 Hostragons의 호스팅 패키지, VPS 서버 및 SSL 인증서 솔루션을 검토하여 프로젝트에 적합한 시작점을 선택할 수 있습니다.

자주 묻는 질문

Nginx 서버 블록으로 몇 개의 사이트를 호스팅할 수 있나요?

기술적으로 Nginx로 동일한 서버에서 많은 수의 사이트를 호스팅할 수 있습니다. 한계는 일반적으로 CPU, RAM, 디스크, 트래픽, 데이터베이스 부하 및 PHP-FPM 용량에 따라 달라집니다. 저트래픽 정적 사이트에서는 수십 개의 사이트가 가능하지만, 고트래픽 WordPress 또는 전자상거래 프로젝트에서는 더 적은 수의 사이트를 호스팅하는 것이 더 건강합니다.

각 사이트에 대해 별도의 SSL 인증서가 필요합니까?

네, 각 도메인이나 서브도메인이 HTTPS를 통해 제공될 경우 인증서 범위에 포함되어야 합니다. 개별 인증서를 사용할 수 있는 것 외에도 SAN 또는 와일드카드 인증서를 선택할 수도 있습니다. 중요한 것은 Nginx 443 서버 블록에서 올바른 인증서 파일이 올바른 도메인에 연결되는 것입니다.

Nginx 서버 블록으로 서브도메인을 호스팅할 수 있나요?

네, blog.site.com 또는 panel.site.com과 같은 서브도메인에 대해 별도의 server_name을 정의하고 다른 루트 디렉터리나 다른 백엔드 애플리케이션으로 리디렉션할 수 있습니다. DNS 측면에서 관련 서브도메인에 대한 A 또는 CNAME 레코드를 생성해야 합니다.

sites-available과 sites-enabled의 차이는 무엇인가요?

sites-available은 사용 가능한 구성 파일이 보관되는 장소이며, sites-enabled는 활성화된 구성을 포함합니다. 일반적으로 sites-enabled 내에서 sites-available 파일에 심볼릭 링크를 생성합니다. 이 방법은 사이트를 활성화하고 비활성화하는 것을 더 정리된 방식으로 만들어 줍니다.

틀린 사이트가 열리는 경우 문제가 어디에서 발생하나요?

가장 일반적인 원인은 DNS가 잘못된 IP로 리디렉션되거나, server_name 값이 잘못되었거나, 기본 Nginx 블록이 요청을 잡아내거나, 443 측에서 잘못된 SSL 블록이 작동하는 것입니다. 먼저 DNS 기록을 확인하고, 그 다음 nginx -t 출력을 확인하고, 활성화된 sites-enabled 링크 및 관련 access_log 파일을 검토하세요.