Linux 서버에서 일반적인 사이트 문제를 해결하는 방법

소개

모든 사람은 자신의 웹 서버나 사이트에 한두 번쯤은 문제가 있습니다. 문제가 발생했을 때 확인해야 할 위치와 원인이 될 수 있는 구성 요소를 파악하면 이러한 문제를 가능한 한 빠르고 확실하게 해결하는 데 도움이 됩니다.

이 가이드에서는 사이트를 백업하고 실행할 수 있도록 이러한 문제를 해결하는 방법을 이해하게 됩니다.

어떤 유형의 문제가 일반적입니까?

사이트를 시작하고 실행할 때 직면하게 될 대부분의 문제는 예측 가능한 범위에 속합니다.

아래 섹션에서 이에 대해 더 자세히 살펴보겠지만 지금은 살펴볼 항목의 체크리스트가 있습니다.

웹 서버가 설치되어 있습니까?
웹 서버가 실행 중입니까?
웹 서버 구성 파일의 구문이 정확합니까?
구성한 포트가 열려 있습니까(방화벽에 의해 차단되지 않음)?
DNS 설정이 올바른 위치로 안내하고 있습니까?
문서 루트가 파일 위치를 가리킵니까?
웹 서버가 올바른 색인 파일을 제공하고 있습니까?
파일 및 디렉토리 구조의 권한과 소유권이 정확합니까?
구성 파일을 통해 액세스를 제한하고 있습니까?
데이터베이스 백엔드가 있는 경우 실행 중입니까?
사이트가 데이터베이스에 성공적으로 연결할 수 있습니까?

다음은 사이트가 제대로 작동하지 않을 때 관리자가 겪게 되는 일반적인 문제 중 일부입니다. 일반적으로 다양한 구성 요소의 로그 파일을 살펴보고 브라우저에 표시된 오류 페이지를 참조하여 정확한 문제의 범위를 좁힐 수 있습니다.

아래에서는 서비스가 올바르게 구성되었는지 확인할 수 있도록 각 시나리오를 살펴보겠습니다.

로그 확인

맹목적으로 문제를 추적하기 전에 웹 서버 및 관련 구성 요소의 로그를 확인하십시오. 이들은 일반적으로 서비스에 특정한 하위 디렉토리의 /var/log에 있습니다.

예를 들어 Ubuntu 서버에서 실행 중인 Apache 서버가 있는 경우 기본적으로 로그는 /var/log/apache2에 보관됩니다. 어떤 종류의 오류 메시지가 생성되고 있는지 보려면 이 디렉토리의 파일을 확인하십시오. 문제를 일으키는 데이터베이스 백엔드가 있는 경우 해당 로그도 /var/log에 보관할 것입니다.

확인해야 할 다른 사항은 서비스가 시작될 때 프로세스 자체가 오류 메시지를 남기는지 여부입니다. 웹 페이지를 방문하려고 시도하고 오류가 발생하면 오류 페이지에도 단서가 포함될 수 있습니다(로그 파일의 행만큼 구체적이지는 않지만).

검색 엔진을 사용하여 올바른 방향으로 안내할 수 있는 관련 정보를 찾으십시오. 대부분의 경우 로그 스니펫을 검색 엔진에 직접 붙여넣어 동일한 문제의 다른 예를 찾는 것이 도움이 될 수 있습니다. 아래 단계는 추가 문제 해결에 도움이 될 수 있습니다.

웹 서버가 설치되어 있습니까?

사이트를 올바르게 제공하기 위해 가장 먼저 필요한 것은 웹 서버입니다. 경우에 따라 웹 페이지가 Docker 컨테이너 또는 일부 다른 애플리케이션에 의해 직접 제공될 수 있으며 실제로 전용 웹 서버를 설치할 필요가 없지만 대부분의 배포에는 여전히 하나 이상이 포함됩니다.

대부분의 사람들은 이 시점에 도달하기 전에 서버를 설치했지만 다른 패키지 작업을 수행할 때 실제로 실수로 서버를 제거했을 수 있는 상황이 있습니다.

Ubuntu 또는 Debian 시스템에 있고 Apache 웹 서버를 설치해야 하는 경우 다음을 입력할 수 있습니다.

sudo apt-get update
sudo apt-get install apache2

이러한 시스템에서 Apache 프로세스는 apache2라고 합니다.

Ubuntu 또는 Debian을 실행 중이고 Nginx 웹 서버를 원하는 경우 대신 다음을 입력할 수 있습니다.

sudo apt-get update
sudo apt-get install nginx

이러한 시스템에서 Nginx 프로세스는 nginx라고 합니다.

RHEL, Rocky Linux 또는 Fedora를 실행 중이고 Apache 웹 서버를 사용해야 하는 경우 다음을 입력할 수 있습니다.

sudo dnf install httpd

이러한 시스템에서 Apache 프로세스는 httpd라고 합니다.

RHEL, Rocky Linux 또는 Fedora를 실행 중이고 Nginx를 사용하려는 경우 다음을 입력할 수 있습니다. 다시 말하지만 루트로 로그인한 경우 "sudo\를 제거하십시오.

sudo dnf install nginx

이러한 시스템에서 Nginx 프로세스는 nginx라고 합니다. Ubuntu와 달리 Nginx는 이러한 RPM 기반 배포판에 설치된 후 자동으로 시작되지 않습니다. 시작 방법을 알아보려면 계속 읽어보세요.

웹 서버가 실행 중입니까?

이제 서버가 설치되었는지 확인했으므로 실행 중입니까?

서비스가 실행 중인지 여부를 확인하는 방법에는 여러 가지가 있습니다. 크로스 플랫폼인 한 가지 방법은 netstat 명령을 사용하는 것입니다.

-plunt 플래그와 함께 netstat를 실행하면 서버에서 포트를 사용하는 모든 프로세스를 알 수 있습니다. netstat 실행에 대한 자세한 내용은 Top, Netstat, Du 및 기타 도구를 사용하여 서버 리소스를 모니터링하는 방법을 참조할 수 있습니다. 그런 다음 찾고 있는 프로세스의 이름에 대한 netstat의 출력을 grep할 수 있습니다.

sudo netstat -plunt | grep nginx

Outputtcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      15686/nginx: master
tcp6       0      0 :::80                   :::*                    LISTEN      15686/nginx: master

nginx를 서버의 웹 서버 프로세스 이름으로 변경할 수 있습니다. 위와 같은 줄이 보이면 프로세스가 실행 중임을 의미합니다. 출력이 반환되지 않으면 잘못된 프로세스를 쿼리했거나 웹 서버가 실행되고 있지 않음을 의미합니다.

웹 서버가 실행되고 있지 않으면 Linux 배포판의 초기화 시스템을 사용하여 시작할 수 있습니다. 백그라운드에서 실행되도록 설계된 대부분의 소프트웨어는 설치 후 init 시스템에 등록되므로 프로그래밍 방식으로 시작하고 중지할 수 있습니다. 또한 대부분의 배포판은 systemctl 명령을 제공하는 동일한 초기화 시스템인 systemd를 사용합니다.

예를 들어 다음을 입력하여 nginx 서비스를 시작할 수 있습니다.

sudo systemctl start nginx

웹 서버가 시작되면 netstat로 다시 확인하여 모든 것이 올바른지 확인할 수 있습니다.

웹 서버 구성 파일의 구문이 정확합니까?

웹 서버를 시작할 수 없는 경우 이는 일반적으로 구성 파일에 주의가 필요함을 나타냅니다. Apache와 Nginx 모두 구성을 올바르게 구문 분석하려면 구문을 엄격하게 준수해야 합니다.

시스템 서비스에 대한 구성 파일은 일반적으로 프로세스 자체의 이름을 딴 /etc/ 디렉토리의 하위 디렉토리에 있습니다.

예를 들어 다음을 입력하여 Ubuntu에서 Apache의 기본 구성 디렉터리로 이동할 수 있습니다.

cd /etc/apache2

RHEL, Rocky 및 Fedora의 Apache 구성 디렉토리는 해당 프로세스의 RHEL 이름도 반영합니다.

cd /etc/httpd

구성은 여러 다른 파일에 분산됩니다. 서비스를 시작하려다가 실패하면 일반적으로 문제가 처음 발견된 줄과 구성 파일을 가리키는 오류가 발생합니다. 해당 파일 조사를 시작할 수 있습니다.

이러한 각 웹 서버는 파일의 구성 구문을 검증하는 방법도 제공합니다.

Apache를 사용하는 경우 apache2ctl 또는 apachectl 명령을 사용하여 구성 파일에서 구문 오류를 확인할 수 있습니다.

apache2ctl configtest

OutputAH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1. Set the 'ServerName' directive globally to suppress this message
Syntax OK

Syntax OK는 기본적으로 서버 실행을 방해하는 중대한 오류가 없으며 그 이전에 인쇄된 모든 메시지가 사소한 오류 또는 경고임을 의미합니다. 이 경우 서버의 정규화된 도메인 이름을 안정적으로 확인할 수 없음은 아직 도메인 이름으로 구성되지 않았지만 여전히 IP 주소로 액세스할 수 있습니다.

Nginx 웹 서버가 있는 경우 다음을 입력하여 유사한 테스트를 실행할 수 있습니다.

sudo nginx -t

Outputnginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

/etc/nginx/nginx.conf의 구성 줄 끝에서 세미콜론을 제거하면(Nginx 구성의 일반적인 오류) 다음과 같은 메시지가 표시됩니다.

sudo nginx -t

Outputnginx: [emerg] invalid number of arguments in "tcp_nopush" directive in /etc/nginx/nginx.conf:18
nginx: configuration file /etc/nginx/nginx.conf test failed

Nginx가 문장을 종료하기 위해 세미콜론을 찾기 때문에 잘못된 개수의 인수가 있습니다. 찾지 못하면 다음 줄로 내려가 마지막 줄에 대한 추가 인수로 해석합니다.

파일에서 구문 문제를 찾기 위해 이러한 테스트를 실행할 수 있습니다. 파일이 테스트를 통과할 수 있을 때까지 참조하는 문제를 수정하십시오.

구성한 포트가 열려 있습니까?

일반적으로 웹 서버는 HTTP 웹 트래픽의 경우 포트 80에서 실행되고 TLS/SSL로 암호화된 HTTPS 트래픽의 경우 포트 443을 사용합니다. 사용자가 사이트에 도달하려면 이러한 포트에 액세스할 수 있어야 합니다.

로컬 시스템에서 netcat을 실행하여 서버의 포트가 열려 있는지 테스트할 수 있습니다.

원격 서버의 IP 주소를 사용하고 다음과 같이 확인할 포트를 지정해야 합니다.

nc -z 111.111.111.111 80

이렇게 하면 111.111.111.111의 서버에서 포트 80이 열려 있는지 확인합니다. 열려 있으면 명령이 즉시 반환됩니다. 열려 있지 않으면 명령이 계속 연결을 시도하지만 실패합니다. 터미널 창에서 CTRL+C를 눌러 이 프로세스를 중지할 수 있습니다.

웹 포트에 액세스할 수 없는 경우 방화벽 구성을 확인해야 합니다. 포트 80 또는 포트 443을 열어야 할 수도 있습니다.

DNS 설정이 올바른 위치로 안내하고 있습니까?

IP 주소로 사이트에 연결할 수 있지만 설정한 도메인 이름으로는 연결할 수 없는 경우 DNS 설정을 살펴봐야 할 수 있습니다.

방문자가 도메인 이름을 통해 사이트에 도달하려면 DNS 설정에서 서버의 IP 주소를 가리키는 "A\ 또는 "AAAA\ 레코드가 있어야 합니다. 로컬에서 host 명령을 사용하거나 다음을 사용하여 도메인의 "A\ 레코드를 쿼리할 수 있습니다.

host -t A example.com

Output
example.com has address 93.184.216.119

반환되는 라인은 서버의 IP 주소와 일치해야 합니다. "AAAA\ 레코드(IPv6 연결용)를 확인해야 하는 경우 다음을 입력할 수 있습니다.

host -t AAAA example.com

Output
example.com has IPv6 address 2606:2800:220:6d:26bf:1447:1097:aa7

DNS 레코드에 대한 모든 변경 사항은 도메인 이름 등록 기관에 따라 전파하는 데 어느 정도 시간이 걸릴 수 있습니다. 때때로 https://www.whatsmydns.net/과 같은 사이트를 사용하여 DNS 변경 사항이 전 세계적으로 적용되는 시기(보통 30분 정도)를 확인하는 것이 도움이 될 수 있습니다. 요청이 아직 모두 최신 상태가 아닌 다른 서버에 도달하는 경우가 많기 때문에 변경 후 이러한 쿼리에 대해 일관되지 않은 결과를 받을 수 있습니다.

DigitalOcean을 사용하는 경우 여기에서 도메인에 대한 DNS 설정을 구성하는 방법을 알아볼 수 있습니다.

구성 파일도 도메인을 올바르게 처리하는지 확인하십시오.

DNS 설정이 올바른 경우 Apache 가상 호스트 파일 또는 Nginx 서버 블록 파일을 확인하여 도메인에 대한 요청에 응답하도록 구성되었는지 확인할 수도 있습니다.

Apache에서 가상 호스트 파일은 다음과 같습니다.

&lt;VirtualHost *:80&gt;
    ServerName example.com
    ServerAlias www.example.com
    ServerAdmin admin@example.com
    DocumentRoot /var/www/html
. . .

이 가상 호스트는 도메인 example.com에 대한 포트 80의 모든 요청에 응답하도록 구성됩니다.

Nginx의 유사한 청크는 다음과 같이 보일 수 있습니다.

server {
    listen 80 default_server;
    listen [::]:80 default_server ipv6only=on;
    root /usr/share/nginx/html;
    index index.html index.htm;
    server_name example.com www.example.com;
. . .

이 두 블록은 동일한 기본 유형의 요청에 응답하도록 구성됩니다.

문서 루트가 파일 위치를 가리키나요?

또 다른 고려 사항은 웹 서버가 올바른 파일 위치를 가리키는지 여부입니다.

Apache의 각 가상 서버 또는 Nginx의 서버 블록은 특정 포트 또는 로컬 디렉터리를 가리키도록 구성됩니다. 이것이 잘못 구성되면 페이지에 액세스하려고 할 때 서버에서 오류 메시지를 표시합니다.

Apache에서 문서 루트는 DocumentRoot 지시문을 통해 구성됩니다.

&lt;VirtualHost *:80&gt;
    ServerName example.com
    ServerAlias www.example.com
    ServerAdmin admin@example.com
    DocumentRoot /var/www/html
. . .

이 행은 Apache에게 /var/www/html 디렉토리에서 이 도메인에 대한 파일을 찾아야 한다고 지시합니다. 파일이 다른 곳에 보관되어 있는 경우 올바른 위치를 가리키도록 이 행을 수정해야 합니다.

Nginx에서 root 지시문은 동일한 것을 구성합니다.

server {
    listen 80 default_server;
    listen [::]:80 default_server ipv6only=on;
    root /usr/share/nginx/html;
    index index.html index.htm;
    server_name example.com www.example.com;
. . .

이 구성에서 Nginx는 /usr/share/nginx/html 디렉터리에서 이 도메인에 대한 파일을 찾습니다.

웹 서버가 올바른 색인 파일을 제공하고 있습니까?

문서 루트가 올바르고 사이트 또는 사이트의 디렉토리 위치로 이동할 때 색인 페이지가 올바르게 제공되지 않는 경우 색인이 잘못 구성되었을 수 있습니다.

웹 애플리케이션의 복잡성에 따라 많은 웹 서버가 여전히 기본적으로 인덱스 파일을 제공합니다. 구성에 따라 일반적으로 index.html 파일 또는 index.php 파일입니다.

Apache에서는 가상 호스트 파일에서 다음과 같이 특정 디렉터리에 대해 명시적으로 사용될 인덱스 순서를 구성하는 줄을 찾을 수 있습니다.

&lt;Directory /var/www/html&gt;
    DirectoryIndex index.html index.php
&lt;/Directory&gt;

즉, 디렉토리가 제공될 때 Apache는 먼저 index.html이라는 파일을 찾고 index.php가 첫 번째 파일인 경우 백업으로 제공하려고 시도합니다. 찾을 수 없습니다.

서버의 기본값을 설정하는 mods-enabled/dir.conf 파일을 편집하여 전체 서버에 인덱스 파일을 제공하는 데 사용할 순서를 설정할 수 있습니다. 서버가 색인 파일을 제공하지 않는 경우 파일의 옵션 중 하나와 일치하는 색인 파일이 디렉토리에 있는지 확인하십시오.

Nginx에서 이를 수행하는 디렉티브는 index라고 하며 다음과 같이 사용됩니다.

server {
    listen 80 default_server;
    listen [::]:80 default_server ipv6only=on;
    root /usr/share/nginx/html;
    index index.html index.htm;
    server_name example.com www.example.com;
. . .

권한 및 소유권이 올바르게 설정되어 있습니까?

웹 서버가 파일을 올바르게 제공하려면 파일을 읽을 수 있어야 하고 파일이 보관된 디렉토리에 액세스할 수 있어야 합니다. 이는 파일 및 디렉터리 권한과 소유권을 통해 제어할 수 있습니다.

파일을 읽으려면 콘텐츠가 포함된 디렉터리를 웹 서버와 연결된 사용자 계정으로 읽고 실행할 수 있어야 합니다. Ubuntu 및 Debian에서 Apache 및 Nginx는 www-data 그룹의 구성원인 www-data 사용자로 실행됩니다.

RHEL, Rocky 및 Fedora에서 Apache는 apache 그룹에 속하는 apache라는 사용자로 실행됩니다. Nginx는 nginx 그룹의 일부인 nginx라는 사용자 아래에서 실행됩니다.

이를 염두에 두고 호스팅 중인 파일과 폴더를 볼 수 있습니다.

ls -l /path/to/web/root

디렉토리는 웹 사용자 또는 그룹이 읽고 실행할 수 있어야 하며 파일은 내용을 읽기 위해 읽을 수 있어야 합니다. 콘텐츠를 업로드, 쓰기 또는 수정하려면 디렉터리에 추가로 쓰기 가능해야 하며 파일도 쓰기 가능해야 합니다.

파일 소유권을 수정하려면 chown을 사용할 수 있습니다.

sudo chown user_owner:group_owner /path/to/file

이 작업은 디렉터리에서도 수행할 수 있습니다. -R 플래그를 전달하여 디렉토리와 그 아래에 있는 모든 파일의 소유권을 변경할 수 있습니다.

sudo chown -R user_owner:group_owner /path/to/file

권한에 대한 자세한 내용은 Linux 권한 소개를 참조하십시오.

구성 파일을 통해 액세스를 제한하고 있습니까?

제공하려는 파일의 액세스를 거부하도록 웹 서버 설정을 구성할 수도 있습니다.

Apache에서는 해당 사이트의 가상 호스트 파일에서 구성하거나 디렉토리 자체에 있는 .htaccess 파일을 통해 구성합니다.

이러한 파일 내에서 몇 가지 다른 방법으로 액세스를 제한할 수 있습니다. 디렉토리는 Apache 2.4+에서 다음과 같이 제한할 수 있습니다.

&lt;Directory /usr/share&gt;
    AllowOverride None
    Require all denied
&lt;/Directory&gt;

Nginx에서 이러한 제한은 deny 지시문의 형태를 취하고 서버 블록 또는 기본 구성 파일에 위치합니다.

location /usr/share {
    deny all;
}

데이터베이스 백엔드가 있는 경우 실행 중입니까?

사이트가 MySQL, PostgresSQL, MongoDB 등과 같은 데이터베이스 백엔드에 의존하는 경우 해당 사이트가 가동되고 사용 가능한지 확인해야 합니다.

웹 서버가 실행 중인지 확인했던 것과 동일한 방식으로 수행할 수 있습니다. 다시, netstat 및 grep을 사용하여 실행 중인 프로세스를 검색할 수 있습니다.

sudo netstat -plunt | grep mysql

Output
tcp        0      0 127.0.0.1:3306        0.0.0.0:*         LISTEN      3356/mysqld

보시다시피 이 시스템에서 서비스가 실행 중입니다. 검색할 때 서비스가 실행되는 이름을 알고 있어야 합니다.

대안은 서비스가 실행되는 포트를 검색하는 것입니다. 데이터베이스 설명서를 참조하여 데이터베이스가 실행되는 기본 포트(MySQL 기본값은 3356)를 찾거나 구성 파일을 확인하십시오.

데이터베이스 백엔드가 있는 경우 사이트를 성공적으로 연결할 수 있습니까?

데이터베이스 백엔드 문제를 해결하는 경우 수행할 다음 단계는 올바르게 연결할 수 있는지 확인하는 것입니다. 이는 일반적으로 사이트에서 데이터베이스 정보를 찾기 위해 읽는 파일을 확인하는 것을 의미합니다.

예를 들어 WordPress 사이트의 경우 데이터베이스 연결 설정은 wp-config.php라는 파일에 저장됩니다. 사이트에서 데이터베이스에 연결하려면 DB_NAME, DB_USER 및 DB_PASSWORD가 올바른지 확인해야 합니다.

명령줄에서 수동으로 데이터베이스에 연결을 시도하여 파일에 올바른 정보가 있는지 테스트할 수 있습니다. 대부분의 데이터베이스는 MySQL과 유사한 구문을 지원합니다.

mysql -u DB_USER_value -pDB_PASSWORD_value DB_NAME_value

파일에서 찾은 값을 사용하여 연결할 수 없는 경우 데이터베이스의 액세스 권한을 수정해야 할 수 있습니다.

다른 모든 방법이 실패하면 로그를 다시 확인하십시오.

로그를 확인하는 것이 실제로 첫 번째 단계이지만 더 많은 도움을 요청하기 전에 좋은 마지막 단계이기도 합니다.

스스로 문제를 해결할 수 있는 능력이 한계에 도달하여 도움이 필요한 경우 로그 파일과 오류 메시지를 제공하여 관련 도움을 더 빨리 받을 수 있습니다. 숙련된 관리자는 필요한 정보를 제공하면 무슨 일이 일어나고 있는지 잘 알 수 있습니다.

결론

이 문제 해결 팁이 관리자가 사이트를 시작하고 실행하려고 할 때 직면하는 일반적인 문제를 추적하고 수정하는 데 도움이 되었기를 바랍니다.

추가적으로 확인해야 할 사항이나 해결 방법이 있다면 댓글로 다른 유저들과 공유해주세요.