Bluehost VPS WHM 로그인 안 열릴 때(SSH 정상) 방화벽 타임아웃 해결

SSH는 접속되는데 WHM(2087) 로그인 화면이 안 열릴 때 Bluehost VPS에서 바로 해결하는 방법

Bluehost VPS로 워드프레스를 운영하다 보면, SSH(22)는 멀쩡히 붙는데 WHM(2087)은 브라우저에서 안 열리는 상황이 종종 나옵니다. 화면이 하얗게 뜨거나 타임아웃이 나고, “서버 문제인가?” 싶어도 정작 서버 안에서는 서비스가 잘 돌고 있는 경우가 많죠.

이럴 때는 대개 서버 내부 방화벽보다 Bluehost 쪽 외부 네트워크 방화벽(인바운드 규칙)이 원인입니다. 아래 내용대로 확인해 보면, “무조건 서버를 만져야 하나?” 같은 고민 없이 빠르게 감이 잡힙니다.

---

SSH는 되는데 WHM이 안 되는 대표 증상

• SSH 접속은 정상 (포트 22 OK)
• WHM 접속 실패 (https://서버IP:2087)
• 브라우저에서 타임아웃/연결 실패/무응답
• 서버 안에서는 cPanel/WHM 서비스가 돌아가는 듯 보임

이 조합이면, 우선 “WHM 서비스가 죽었나?”부터 확인하고, 다음으로 “포트는 열려 있나?”를 확인합니다. 여기까지 서버에서 정상인데도 밖에서만 안 열리면, 대부분 Bluehost 인바운드 규칙 문제로 귀결됩니다.

---

서버에서 WHM 서비스가 살아 있는지 확인

SSH로 접속한 뒤 아래 명령으로 cpsrvd 프로세스를 확인합니다.

ps -ef | grep cpsrvd | grep -v grep

정상이라면 다음과 비슷한 결과를 확인할 수 있습니다.

cpsrvd (SSL) - waiting for connections

이 문구가 나오면 WHM(=cpsrvd)이 접속을 기다리는 상태라서, “서비스가 죽어서 접속이 안 되는” 케이스는 아닙니다.

---

2087 포트가 서버에서 실제로 열려 있는지 확인

서비스가 살아 있어도 포트가 리슨 중인지 한 번 더 확인합니다.

ss -lntp | grep 2087

정상 출력 예시:

LISTEN 0 128 0.0.0.0:2087

LISTEN이 보이면 서버 내부에서는 2087이 열려 있다는 뜻입니다. 이 상태에서 외부 브라우저만 실패하면, “외부에서 서버까지 들어오는 길”이 막혀있을 확률이 올라갑니다.

---

서버 내부 방화벽(로컬) 확인

Firewalld 확인

firewall-cmd --list-ports

예시로 아래처럼 나온다면:

Firewalld is not running

서버 내부 방화벽이 동작 중이 아니라는 의미입니다. 즉, firewalld 때문에 2087이 막히는 구조는 아닙니다.

CSF(cPanel Firewall) 사용 여부 확인

csf -l

아래처럼 나오면:

command not found

CSF 자체가 설치되어 있지 않은 상태입니다. 로컬 방화벽 이슈는 거의 배제할 수 있습니다.

---

결론: Bluehost 인바운드 규칙에서 2087이 막힌 경우가 많다

지금까지 체크한 게 모두 정상인데도 WHM이 안 열리면, 결론은 꽤 단순합니다.

Bluehost 쪽 외부 방화벽(인바운드 규칙)에서 2087/TCP를 허용하지 않아서 접속이 막히는 경우가 대부분입니다. 특히 SSH(22)는 기본 허용, 관리 콘솔 포트(2087)는 기본 제한으로 구성되는 일이 흔합니다.

---

Bluehost에서 WHM(2087) 열어두기

Bluehost 관리자 화면에서 설정

1) Bluehost 접속

https://my.bluehost.com

2) VPS에서 Manage 선택

VPS 목록에서 대상 서버를 선택한 뒤 Manage로 들어갑니다.

3) Security / Firewall / Networking 메뉴로 이동

계정 화면 구성에 따라 메뉴명이 다르게 보일 수 있는데, 핵심은 Inbound(인바운드) 규칙을 편집하는 곳을 찾는 겁니다.

4) Inbound Rules(또는 Incoming Traffic)에서 규칙 추가

Protocol	TCP
Port	2087
Source	0.0.0.0/0 (권장하지 않음) 또는 내 IP만
Action	ALLOW

형태는 아래처럼 들어갑니다.

Type: Custom
Protocol: TCP
Port: 2087
Allow from: Anywhere

가능하면 Source는 내 IP로 제한해 두는 게 안전합니다. (WHM은 관리자 콘솔이라 열어두면 공격 시도도 같이 늘어납니다.)

5) 저장/적용

Save/Apply 후 1~2분 정도 뒤에 접속을 다시 시도합니다.

---

WHM 접속 확인

브라우저에서 아래 주소로 접속합니다.

https://서버IP:2087

정상이라면 WHM 로그인 화면이 바로 뜹니다. 이전에 타임아웃이던 환경이라면, 체감상 바로 바뀌는 경우가 많습니다.

---

보안 체크: SSH 실패 로그가 많다면 먼저 의심해야 할 것

로그인 직후 아래 문구를 본 적 있다면:

There were XX failed login attempts

서버가 이미 스캔/대입 공격을 받고 있을 가능성이 큽니다. WHM을 열었다면, 최소한 아래 항목은 같이 챙겨두는 게 마음이 편합니다.

• WHM 2FA 활성화
• SSH 키 로그인 사용 (비밀번호 접속 최소화)
• SSH 포트 변경 또는 특정 IP만 허용
• Fail2ban 적용
• 관리자 계정 비밀번호 강도 강화

---

같은 문제 재발 방지용 체크리스트

• 서버에서 cpsrvd가 살아 있는지 확인
• 서버에서 2087 LISTEN 상태 확인
• 서버 내부 방화벽(firewalld/ufw/csf) 여부 확인
• Bluehost 인바운드 규칙에 2087/TCP 허용이 있는지 확인
• 가능하면 내 IP만 허용으로 제한

---

외부 포트를 열지 않고 WHM 접속하는 방법(SSH 터널)

WHM을 “어디서나 접속” 가능하게 열어두는 건 편하지만, 그만큼 노출도 같이 늘어납니다.

Bluehost 인바운드에서 2087을 아예 막아둔 상태로도 WHM을 사용하는 방법이 있습니다. 핵심은 SSH 터널입니다.

로컬 PC에서 터널 연결

ssh -L 2087:127.0.0.1:2087 root@서버IP

브라우저 접속

https://127.0.0.1:2087

이 방식은 2087을 외부에 열지 않아도 되기 때문에, 관리자 콘솔 보안 측면에서 선호되는 방법입니다.

---

이어지는 글: WHM을 열어둔 뒤 바로 적용하면 좋은 최소 보안 세팅

WHM이 열리는 순간부터 접속 시도도 늘어날 수 있습니다. 아래는 “당장 부담 없이” 적용하는 쪽으로 많이들 정리하는 항목입니다.

WHM에서 바로 켤 수 있는 것

• Two-Factor Authentication 켜기
• 관리자 계정 비밀번호 교체 및 강도 강화
• 사용하지 않는 계정/리셀러 접근 정리

SSH 쪽에서 자주 챙기는 것

• 가능하면 키 인증 위주로 전환
• SSH 접속 가능 IP 제한(사무실/집/고정 IP)
• Fail2ban으로 반복 시도 자동 차단

---

자주 묻는 질문(FAQ)

Q. SSH에서는 cpsrvd가 살아 있는데, 브라우저에서만 2087이 타임아웃나요.
A. 서버 내부가 정상이라면, 거의 항상 Bluehost 인바운드 규칙에서 2087/TCP가 허용되지 않은 상황입니다. 인바운드에 추가 후 바로 재시도해 보세요.

Q. 2087을 0.0.0.0/0로 열어도 되나요?
A. 가능은 하지만 권장하지 않습니다. WHM은 공격 표적이 되기 쉬워서 내 IP만 허용하거나, 아예 SSH 터널로만 접속하는 쪽이 안전합니다.

Q. 2087을 열었는데도 “연결 거부(Connection refused)”가 떠요.
A. 이 경우는 외부 차단보다는 서버에서 2087이 리슨 중이 아닌 상태일 때 자주 나옵니다. ss -lntp | grep 2087로 LISTEN 여부를 다시 확인해 보세요.

Q. WHM 포트를 열었더니 실패 로그인 시도가 더 늘었습니다.
A. 정상입니다. 노출이 늘면 스캔도 늘어납니다. 2FA + 접근 IP 제한을 같이 적용하는 게 가장 체감이 큽니다.

Q. 워드프레스만 쓰는데 WHM이 꼭 필요한가요?
A. 서버를 직접 관리하는 환경(VPS/전

• Bluehost VPS: WHM 로그인 안 열릴 때(SSH 정상) 방화벽 타임아웃 해결

용)이라면 WHM이 편합니다. 다만 워드프레스만 운영한다면, WHM보다 보안/백업/업데이트 체계를 먼저 안정화하는 게 더 중요할 때도 많습니다.