HestiaCP 워드프레스 500 오류 해결

- Vultr 헤스티아 컨트롤 패널 서버에서 Apache 구문 오류

Aug 13. 2025

Vultr 서버에서 HestiaCP를 이용해 워드프레스 사이트를 운영하는 경우, 예기치 않은 500 Internal Server Error로 인해 워드프레스 사이트에 접속할 수 있는 문제가 발생하는 경우가 있습니다. 이 글에서는 Nginx와 Apache 간 업스트림 오류, 잘못된 포트 설정, apache2.conf 구문 오류 등 복합적인 원인으로 발생한 500 오류의 실제 사례를 바탕으로 문제 해결 방법을 간략히 소개합니다.

벌처에서 헤스티아 패널이나 CyberPanel을 사용하면 서버를 손쉽게 관리할 수 있습니다. 하지만 가끔 서버 수준에서 오류가 발생하면 당황스러운 상황에 처할 수 있습니다. 서버 운영 지식이 있다면 스스로 문제를 해결할 수 있지만, 그렇지 않다면 비용을 들여 전문가에게 맡기거나, 심하면 서버를 복구하지 못해 사이트를 포기하는 경우도 있습니다.

Vultr나 AWS처럼 직접 서버를 관리하기 부담스럽다면, 최근 국내에서도 많이 사용하는 클라우드웨이즈(Cloudways)를 고려할 만합니다. 방문자가 많거나 속도가 중요한 사이트, 또는 여러 개의 사이트를 운영할 계획이라면 좋은 선택이 될 수 있습니다. 블로그를 막 시작한 경우에는 가성비가 뛰어나고 서울 서버를 제공해 국내에서도 속도가 빠른 케미클라우드(ChemiCloud)가 좋은 대안이 될 수 있습니다.

�클라우드웨이즈 가입 방법 (+ 45% 할인 쿠폰)

클라우드웨이즈(Cloudways)는 큰 규모의 사이트(워드프레스 포함)를 운영하거나 빠른 사이트 속도를 원하는 경우 고려해볼 수 있습니다. 클라우드웨이즈를 통해 아마존 AWS...

https://cafe.naver.com/wphomepage/30596

Vultr 서버의 HestiaCP 패널에서 운영되는 워드프레스 사이트에서 500 오류 해결

이번 사례는 Vultr 서버의 HestiaCP 환경에서 운영 중인 워드프레스 사이트에서 500 Internal Server Error가 발생한 상황을 다룹니다. SFTP로 테스트 파일을 업로드해도 동일한 오류 화면이 나왔기 때문에, 단순 워드프레스 문제가 아닌 웹서버 레벨의 오류로 판단되었습니다.

Vultr + HestiaCP 환경은 관리 패널과 서버 운영이 비교적 쉬운 장점이 있습니다만, 서버 레벨에서의 오류가 발생하면 스스로 복구가 어려울 수 있습니다. 따라서 정기적인 백업이 필수적이며, 문제가 심각할 경우 서버 재생성이나 다른 호스팅으로의 이전을 준비해야 합니다.

오류 로그를 확인한 결과, Nginx가 포트 8443(헤스티아 관리용)에 프록시 시도했지만 연결이 거부되어 응답이 없다는 기록이 확인되었습니다. 즉, 클라이언트 요청이 백엔드로 지정된 잘못된 포트로 전달되고 있었던 것이 문제의 핵심입니다.

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

이 문제는 Nginx가 Apache나 PHP‑FPM이 아닌 관리 패널 포트로 업스트림을 연결했기 때문에 발생했습니다. 따라서 HestiaCP의 Web Template/Proxy Template을 워드프레스 또는 Default 템플릿으로 재설정하고 v-rebuild-web-domain 명령으로 설정을 재빌드해야 오류가 해결될 수 있습니다.

하지만 템플릿 재설정 후 Apache 재시작에서 apache2.conf의 구문 오류(syntax error)로 인해 아파치 서버 재가동이 실패했고, Nginx 프록시는 연결 거부 상태였기 때문에 결국 500 Internal Server Error가 해결되지 않았습니다.

최종적으로 Apache 설정 파일의 문법 오류를 수정한 후 Apache가 정상적으로 재시작되면서, Nginx와 백엔드 간 업스트림 연결이 복구되어 사이트가 정상적으로 작동하기 시작했습니다. 오류의 근본 원인은 apache2.conf 파일이 누군가에 의해 손상된 것으로 추정되었습니다.

클라이언트는 이전에 KBoard 게시글 수정 후 숏코드 삽입 및 캐시 플러그인 설정으로 504 (Gateway Timeout) 오류가 일어난 상황이 있었고, 서버 재부팅 이후 해당 문제와 별개로 Apache 설정 오류가 활성화되며 500 오류가 발생한 것으로 보였습니다.