Vultr 서버 문제 해결 - 워드프레스 내부 서버 오류 (Internal Server Error)

Vultr에서 HestiaCP를 설치하여 관리하고 있던 워드프레스 사이트에서 Internal Server Error가 발생하는 문제 해결을 맡았습니다. 서버는 2개였고, 각기 다른 이유로 500 내부 서버 오류가 발생하고 있었습니다. 특히 한 서버에는 사이트 개수가 100개 넘을 정도로 많았습니다. 워드프레스에서는 다양한 문제 Internal Server Error가 발생합니다. 서버 내의 모든 사이트에서 이 오류가 나타난다면 서버 문제일 가능성이 높습니다. 하지만 서버 문제라고 완전히 단정할 수는 없습니다. 예를 들어, 서버 내의 모든 사이트에 동일한 테마나 플러그인이 사용되고 있을 때 자동 업데이트 과정에서 모든 사이트에 이 오류가 발생할 수도 있습니다.

HestiaCP가 설치된 Vultr 서버 문제 해결

저는 클라우드웨이즈(Cloudways)에 모든 워드프레스 사이트를 몰아서 운영하고 있습니다. 클라우드웨이즈가 Vultr에 비해 가격이 비싸지만 쉬운 웹호스팅 관리 대시보드와 365일 연중무휴 라이브 채팅을 통한 서버/워드프레스 관련 문제 문의가 가능하므로 저같이 서버를 직접 생성하여 관리하는 데 부담을 느끼거나 시간이 없는 경우 괜찮은 선택 같습니다.

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

Vultr에서 직접 서버를 생성하여 워드프레스를 운영하려는 경우 웹호스팅 패널로 요즘에는 HestiaCP가 많이 사용되는 것 같습니다. CyberPanel이라는 무료 웹호스팅 패널도 있지만, 기능과 보안 등 여러 가지 이유 때문에 HestiaCP가 요즘은 더 인기가 있는 것으로 생각됩니다.

며칠 전 Vultr에서 호스팅되고 있던 워드프레스 사이트가 접속되지 않는 문제 해결을 의뢰받았습니다. 당시 외부에 있어서 저녁때 작업을 해드릴 수 있다고 하니 시간이 급한 클라이언트께서 아는 지인에게 일을 맡겼습니다. 하지만 무엇을 잘못 건드렸는지 서버가 더 이상해졌다고 하네요.😥

두 개의 서버에서 문제가 발생했는데, 하나는 워드프레스 개수가 14개였지만, 다른 하나는 107개가 있었습니다.

다음 명령을 실행하면 워드프레스 wp-config.php 구성 파일의 개수를 확인하여 대략적인 워드프레스 설치 개수를 추정할 수 있습니다.

ls /home/*/web/*/public_html/wp-config.php 2>/dev/null | wc -l

두 개의 서버가 겉으로 표시되는 오류 메시지는 동일했지만, 문제은 원인은 달랐습니다.

서버 1

서버 1에서는 사이트가 갑자기 열리지 않고 “500 내부 서버 오류”가 표시되었습니다. 확인해 보니 서버 자체가 고장 난 것도, 워드프레스에 문제가 있었던 것도 아니었습니다.

원인은 자동으로 돌아다니는 접속 프로그램(봇)의 공격이었습니다. AionBot이라는 이름의 이 봇은 게시판의 글 수정 및 삭제 링크를 하나도 빠짐없이 따라다니며 요청을 쏟아냈습니다. 이런 링크는 번호 조합만 바꾸면 끝없이 만들어지기 때문에, 봇은 계속 새로운 주소를 요청을 보냈고 서버는 그때마다 처음부터 일을 처리해야 했습니다.

서버가 한 번에 처리할 수 있는 일의 양에는 한계가 있습니다. 봇의 요청에 의해 그 한계가 가득 차면서 진짜 방문자의 요청은 순서를 기다리다 시간이 초과되어 오류 화면을 표시되는 문제가 발생했습니다.

해결은 이 봇을 막는 것에서 시작했습니다. 봇이 사용하던 접속 주소 대역을 차단하고, 서버를 재시작해 쌓인 대기열을 비웠으며, 봇의 이름을 기준으로 서버 입구에서 돌려보내도록 설정했습니다. 그 결과 사이트는 정상으로 돌아왔고, 일반 방문자와 검색엔진에는 영향이 없었습니다.

HestiaCP(헤스티아 컨트롤 패널)에서 방화벽 규칙을 생성하여 특정 IP나 IP 대역을 차단했습니다.

 

서버 2

서버 2에서도 동일한 오류 화면(500 Error)이 나왔지만 원인은 전혀 달랐습니다. 이 서버에는 약 109개의 사이트가 함께 들어 있는데, 그중 일부 사이트의 작업 프로세스가 외부 서버의 응답을 기다리다 멈춘 것이 문제의 시작이었습니다.

사이트가 다른 외부 서버에 연락했는데 상대 서버가 응답을 끝까지 주지 않았고, 이 작업은 "언제까지 기다린다"는 제한이 없어서 약 48시간 동안 그대로 붙잡혀 있었습니다. 이런 멈춘 작업이 해당 사이트들의 처리 공간(작업자 8명 분량)을 모두 차지하자, 새 요청이 줄을 서기 시작했고 줄이 계속 길어졌습니다.

문제는 여기서 끝나지 않았습니다. 서버는 모든 사이트가 공용으로 쓰는 대기 창구가 있는데, 막힌 사이트의 요청이 이 공용 창구까지 가득 채워 버렸습니다. 그 결과 아무 문제가 없던 다른 사이트까지 함께 오류가 발생했습니다. 한 사이트의 문제가 같은 서버의 다른 사이트로 전파된 것입니다.

조사 과정에서 한 가지가 더 발견됐습니다. 이 가운데 특정 사이트에 워드프레스 정상 파일처럼 이름을 위장한 악성 파일 2개가 숨어 있었습니다. 8월 초에 심어진 것으로 보이며, 멈춘 작업이 외부 서버와 통신하던 것과 관련이 있을 가능성이 있습니다.

해결은 멈춘 작업을 정리하고 서버를 재시작해 대기열을 비운 뒤, 한 작업이 일정 시간 이상 붙잡고 있지 못하도록 제한을 둔 것입니다. 문제의 외부 서버로 나가는 연결은 임시로 막았고, 악성 파일이 발견된 계정은 정지해 증거와 함께 보관했습니다. 이후 서버는 안정적으로 유지되고 있습니다.

요약하면, 서버 1은 봇의 과도한 접속, 서버 2는 외부 응답 대기로 멈춘 작업(일부 사이트에서 악성 파일 발견)이 원인이었습니다.

요즘은 AI의 도움을 받아서 서버 오류 해결을 시도해볼 수 있습니다. 하지만 특정 작업을 할 때에는 해당 작업이 어떤 것이며 어떤 영향을 미칠 수 있다는 것을 이해하고 진행해야 안전합니다. 서버에 대한 지식이 없는 상태에서 AI의 말만 듣고 진행하다가 오히려 문제가 꼬여서 더 해결하기 어렵게 될 수도 있습니다.

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

참고

https://avada.tistory.com/3046

해외웹호스팅: 클라우드웨이즈 vs. 블루호스트 vs. 카페24 비교 (Cloudways vs. Bluehost vs. Cafe24)

https://avada.tistory.com/3798

Vultr Hestia 컨트롤 패널: PHP 메모리 크기 설정 및 워드프레스 초기화 작업