Vultr 헤스티아 패널(hestiaCP) 워드프레스의 500 Internal Server Error 문제 해결

Vultr(벌처) 서버의 HestiaCP(헤스티아 컨트롤 패널)에서 운영하는 워드프레스 사이트에 500 Internal Server Error가 발생해 접속이 되지 않는 문제 해결을 맡았습니다. 워드프레스 사이트에 접속하면 아래 그림과 같이 500 오류가 발생했고, SFTP를 통해 테스트 파일을 업로드해 접속을 시도했지만 동일한 화면이 표시되었습니다. 이를 통해 웹 서버 자체가 정상적으로 동작하지 않는 것으로 판단되었습니다.

Vultr에서 헤스티아 패널이나 CyberPanel 등을 이용하면 쉽게 서버를 관리할 수 있지만, 간혹 서버 레벨에서 오류가 발생하여 난감한 상황이 될 수 있습니다. 서버에 대한 지식이 있으면 스스로 해결을 시도해볼 수 있지만, 그렇지 않은 경우에는 비용을 들여 전문가에게 의뢰하거나, 최악의 경우 서버를 복구하지 못해 사이트를 포기하는 사례도 드물지만 본 적이 있습니다. 항상 백업을 받아 놓으면 만약의 사태 발생 시 서버를 다시 생성하여 복구하거나 다른 웹호스팅으로 이전하는 것이 가능합니다.

Vultr, AWS 등의 서버를 쉽게 관리하고 싶은 경우 최근 몇 년 사이 우리나라에서도 많이 이용되고 있는 클라우드웨이즈(Cloudways)를 고려할 수 있습니다. 방문자 수가 많거나 속도가 중요하거나 여러 사이트를 운영하려는 경우 괜찮은 선택일 수 있습니다. 블로그를 시작하는 단계인 경우 가성비가 좋고 서울 서버를 도입하여 우리나라에서도 속도가 좋은 케미클라우드(ChemiCloud)가 하나의 옵션이 될 수 있습니다.

📍 클라우드웨이즈 할인 프로모 코드 & 가입 방법 (+45% 쿠폰)

Vultr 헤스티아 패널(hestiaCP) 워드프레스의 500 Internal Server Error 문제 해결

워드프레스 문제를 비롯하여 어떤 문제든 문제를 해결하려면 먼저 원인을 파악해야 합니다. 서버에 접속하여 오류 로그를 체크해보니 다음과 같은 오류가 발생하는 것을 발견했습니다.

2025/08/12 10:00:03 [error] 998#998: *6 connect() failed (111: Connection refused) while connecting to upstream, client: 198.51.100.25, server: example.com, request: "GET / HTTP/2.0", upstream: "https://203.0.113.10:8443/", host: "example.com", referrer: "https://search.example.net/"
2025/08/12 10:00:03 [error] 998#998: *6 connect() failed (111: Connection refused) while connecting to upstream, client: 198.51.100.25, server: example.com, request: "GET /favicon.ico HTTP/2.0", upstream: "https://203.0.113.10:8443/favicon.ico", host: "example.com", referrer: "https://example.com/"

사용자들이 사이트에 접속할 때마다 ...connect() failed (111: Connection refused) while connecting to upstream... 오류 메시지가 기록되고 있었습니다.

위 로그는 Nginx가 naver-seo.com 요청을 처리하는 과정에서 백엔드로 지정된 203.0.113.10:8443에 연결을 시도했으나, 해당 포트에서 연결이 거부(Connection refused)되어 응답을 받지 못한 상황을 나타냅니다. 클라이언트 IP 198.51.100.25에서 /와 /favicon.ico를 요청했지만, 8443 포트는 HestiaCP 관리 콘솔 포트로 웹 서비스가 동작하는 포트가 아니어서 정상적인 백엔드 응답을 줄 수 없는 상태입니다. 이로 인해 프론트엔드(Nginx)와 백엔드 간 연결이 실패하며 사이트 접속 시 오류가 발생하고 있었습니다.

이 문제를 해결하기 위해서는 Nginx가 잘못된 백엔드 포트(8443)가 아닌 실제 웹 애플리케이션이 동작하는 포트(예: Apache의 8080 또는 PHP-FPM 소켓)로 프록시하도록 설정을 수정해야 합니다. Hestia 패널에서 해당 도메인의 Web Template과 Proxy Template을 default나 워드프레스용 템플릿으로 재설정하고, v-rebuild-web-domain 명령을 통해 도메인 설정을 재빌드한 뒤 Nginx와 Apache/PHP-FPM을 재시작하면 잘못된 업스트림 경로가 교정되어 문제가 해결될 수 있습니다.

헤스티아 패널에 접속하여 웹 템플릿, 백엔드 템플릿, 프록시 템플릿 등을 확인하여 잘못 지정된 템프릿으로 의심되는 것을 default로 변경했습니다.

하지만 저장 버튼을 누르면 Error apache2 restart failed 오류가 발생하면서 아파치 서버 재시작에 실패했습니다.😥

어떤 이유로 인해 Apache가 기동되지 못함 → Nginx가 Apache로 프록시하려다 연결 거부(Connection refused) 발생 → 결과적으로 WordPress 접속 시 500 Error가 표시되는 구조였습니다.

apachectl -t 명령을 실행하여 체크해보니 /etc/apache2/apache2.conf 파일에서 구문 오류(syntax error)가 있어 아파치 웹서버가 재가동되지 못하는 문제가 발생했습니다.

결론적으로 해당 사이트에서는 누군가에 의해 apache2.conf 파일이 수정되어 apache2.conf 구문 오류 → Apache 비정상 → Nginx 업스트림 실패 → 500 Error라는 흐름으로 문제가 발생한 것으로 추정되었습니다.

apache2.conf 파일을 누가 수정했는지는 먼저 체크해보았으면 좋았겠지만 문제 해결이 먼저라는 생각에 미처 확인해야겠다는 생각을 하지 못했습니다. (사용자가 편집하지 않았다면 멀웨어 감염이나 해킹 등의 이유로 수정되었을 가능성도 배제할 수 없습니다.) 😥

클라이언트께 물어보니 문제의 시작은 케이보드(Kboard) 게시글을 수정하고 메인페이지에 숏코드를 넣었는데, 게시글이 최신순으로 나와서 스니펫 플러그인으로 asp 나열로 바꾼 후 10분 정도 지난 후에 504 에러가 발생했고(504 Gateway Timeout 오류는 일반적으로 서버가 요청을 처리하는 데 시간이 너무 오래 걸릴 때 발생함), 서버 재시작 후에는 500 에러가 떴다고 합니다.

메인 페이지에 추가한 숏코드와 정렬 스니펫이 무거운 쿼리를 만들어 504 게이트웨이 타임아웃을 유발했고, 이와 별개로 서버 설정 오류로 인해 500 내부 서버 에러가 발생한 것으로 추정됩니다. 아마 "이전부터 잘못 수정된 conf가 있었지만 프로세스가 살아 있어서 버티던 상태였고, 서버를 재시작하면서 잘못된 conf를 다시 읽다가 Apache가 뜨지 못해 오류가 발생"한 것으로 이해할 수도 있을 것 같습니다.

오류를 해결한 후에 PHP 메모리 제한 크기(PHP Memory Limit)를 256MB에서 512MB로 높였습니다(헤스티아 CP에서 메모리 크기 설정 참조). 하지만 사이트 속도가 매우 느리게 로드되었는데요, 아마도 케이보드 관련 쿼리 때문에 사이트가 버벅대는 것으로 추정되었습니다. (이후에 다시 접속해보니 사이트가 빠르게 로드되었습니다. 아마 문제가 되는 쿼리를 제거한 것 같습니다.)

👉 워드프레스나 웹호스팅 관련 문제로 해결에 어려움을 겪는 경우 여기에서 서비스(유료)를 의뢰하실 수 있습니다.

참고

https://avada.tistory.com/3656

닷홈에서 케미클라우드(ChemiCloud)로 워드프레스 이전 작업

https://avada.tistory.com/3566

아마존 AWS에서 클라우드웨이즈로 워드프레스 멀티사이트 이전 작업

https://avada.tistory.com/3743

Vultr 헤스티아 컨트롤 패널에서 phpMyAdmin 접속 문제 (#1231 - variable 'lc_messages' can't be set to the value of