Vultr(벌처) 서버의 HestiaCP(헤스티아 컨트롤 패널)에서 운영하던 워드프레스 사이트에 500 내부 서버 오류가 발생해 접속이 안 되는 문제 해결을 맡아 작업했습니다. 사이트에 접속하면 그림처럼 Internal Server Error가 뜨고, FTP/SFTP로 테스트 파일을 올려 접속을 시도해도 같은 화면이 나타났습니다. 이로 인해 웹 서버 자체가 정상 작동하지 않는 것을 확인했습니다.
헤스티아 패널이나 사이버패널(CyberPanel)로 Vultr 서버를 관리하면 편리하지만, 때로는 서버 레벨에서 에러가 발생하여 난감한 상황이 발생할 수 있습니다. Linux 서버에 대한 지식이 있으면 스스로 해결할 수 있지만, 그렇지 않은 경우 전문가에게 의뢰하여 해결하거나, 최악의 경우 사이트를 포기해야 하는 상황도 드물지만 접하게 됩니다. 다행히 백업이 있으면 예기치 않은 사고가 발생하더라도 서버를 다시 만들거나 다른 호스팅으로 옮길 수 있습니다.
서버 관리의 편의성을 원한다면 최근 국내에서도 많이 쓰이는 클라우드웨이즈(Cloudways)도 고려해볼 수 있습니다. 방문자 수가 많거나 속도가 중요한 경우, 여러 사이트를 운영해야 한다면 좋은 선택일 수 있습니다. 블로그 시작 단계에는 가성비가 좋고 서울 서버를 제공하는 케미클라우드(ChemiCloud)가 경제적인 옵션일 수 있습니다.
📍 클라우드웨이즈 할인 프로모 코드 & 가입 방법 (+45% 쿠폰)
Vultr VPS HestiaCP 패널에서 발생하는 워드프레스 500 오류 문제 해결
문제를 해결하려면 먼저 원인을 파악해야 합니다. 서버에 접속해 오류 로그를 체크하여 아래와 비슷한 오류를 확인했습니다.
2025/08/14 22:15:47 [error] 1204#1204: *18 connect() failed (111: Connection refused) while connecting to upstream, client: 203.0.113.45, server: mysite.net, request: "POST /wp-login.php HTTP/1.1", upstream: "http://192.0.2.50:8080/wp-login.php", host: "mysite.net", referrer: "https://mysite.net/login"
2025/08/14 22:15:47 [error] 1204#1204: *18 connect() failed (111: Connection refused) while connecting to upstream, client: 203.0.113.45, server: mysite.net, request: "GET /favicon.ico HTTP/1.1", upstream: "http://192.0.2.50:8080/favicon.ico", host: "mysite.net", referrer: "https://mysite.net/wp-login.php"사용자 접속마다 ...connect() failed (111: Connection refused) while connecting to upstream... 메시지가 남아 있었습니다.
위 로그는 Nginx가 mysite.net 요청을 처리하는 과정에서 백엔드로 지정된 192.0.2.50:8080에 연결하려 했으나, 포트에서 연결이 거부되어 응답을 받지 못한 상황을 뜻합니다.
클라이언트 IP 203.0.113.45가 /wp-login.php와 /favicon.ico를 요청했지만, 8080 포트는 워드프레스가 정상 작동하도록 구성되지 않아 백엔드 응답을 줄 수 없었습니다.
이로 인해 프론트엔드(Nginx)와 백엔드 간 연결이 끊겨 로그인 페이지 접속과 리소스 로딩에 오류가 생겼습니다.
해결하려면 Nginx가 잘못된 백엔드 포트(8443)가 아닌 실제 웹 애플리케이션이 동작하는 포트(예: Apache의 8080 또는 PHP-FPM 소켓)로 프록시하도록 설정을 수정해야 합니다. Hestia에서 도메인의 Web Template과 Proxy Template을 워드프레스용으로 재설정하고, v-rebuild-web-domain으로 도메인 정보를 재빌드한 뒤 Nginx와 Apache/PHP-FPM을 재시작하면 업스트림 경로를 바로잡아 문제가 해결될 수 있습니다.
헤스티아 패널에서 웹 템플릿, 백엔드 템플릿, 프록시 템플릿을 확인하고 잘못 지정된 템플릿으로 의심되는 것을 default로 변경했습니다.
하지만 Save(저장) 버튼을 누르면 Error apache2 restart failed 오류가 발생하며 아파치 서버 재시작에 실패했습니다.😥
어떤 이유로 Apache가 기동되지 못함 → Nginx가 Apache로 프록시하려다 연결 거부가 발생해 WordPress 접속 시 500 오류가 표시되는 구조였습니다.
apachectl -t 명령을 실행해 보니 /etc/apache2/apache2.conf 파일에 구문 오류가 있어 Apache가 재가동되지 않는 문제가 확인되었습니다.
결론적으로 해당 사이트는 누군가 apache2.conf를 수정해 구문 오류를 만들고, Apache 비정상 → Nginx 업스트림 실패 → 500 에러로 이어진 것으로 추정했습니다.
누가 수정했는지 확인하는 것이 좋았겠지만, 당시 누가 수정했는지를 확인해야겠다는 생각을 미처 하지 못했습니다. 사용자가 편집하지 않았다면 멀웨어 감염이나 해킹으로 수정되었을 가능성도 배제할 수 없을 것 같습니다. 😥
클라이언트에 의하면 문제의 시작은 케보드(Kboard) 게시글 수정과 메인페이지 숏코드 삽입에서 비롯되었다고 합니다. 게시글이 최신순으로 표시되자 스니펫 플러그인으로 ASP 나열로 바꾼 뒤 약 10분쯤 지나 504 Gateway Timeout이 발생했고, 서버 재시작 후에는 500이 나타났다고 합니다.
메인 페이지에 추가한 숏코드와 정렬 스니펫이 무거운 쿼리를 만들어 504 게이트웨이 타임아웃을 유발했고, 서버 설정 오류로 인해 500 오류가 생긴 것으로 보입니다. 케이보드 관련 수정을 하기 전에 구성 파일이 잘못 수정되었지만 프로세스가 살아 버티던 상태였고, 서버 재시작 시 잘못된 설정을 읽으면서 Apache가 시작되지 못해 오류가 발생한 것이 아닐가 추정되었습니다.
오류를 해결한 뒤 PHP 메모리 제한을 256MB에서 512MB로 올렸습니다(헤스티아 CP에서 메모리 크기 설정). 다만 사이트 속도가 매우 느려졌고, 이는 케보드 관련 쿼리 탓일 가능성이 큽니다. 이후 재접속해 보니 속도가 빨라졌고, 문제가 된 쿼리를 제거한 것으로 보였습니다.
👉 워드프레스나 웹호스팅 문제로 해결이 어려움을 겪는다면 여기에서 유료 서비스 이용을 고려해 보세요.