서버는 켜져 있는데 접속이 안 될 때 확인할 것｜IT 운영자가 보는 장애 점검 순서

서버는 켜져 있는데 시스템 접속이 안 될 때 IT 운영자가 확인해야 할 항목을 정리했습니다. URL, DNS, ping, 포트, 방화벽, 웹서버, WAS, 서버 리소스, 애플리케이션 로그, DB 연결, 로드밸런서, SSL 인증서까지 장애 점검 순서를 실무 기준으로 설명합니다.

 

IT 운영 업무를 하다 보면 사용자가 시스템에 접속하지 못한다고 문의했는데, 막상 서버를 확인해보면 서버 자체는 켜져 있는 경우가 있습니다.

사용자는 보통 이렇게 문의합니다.

“시스템 접속이 안 됩니다.”
“서버는 살아 있다고 하는데 화면이 안 열립니다.”
“사이트가 계속 로딩되다가 실패합니다.”
“특정 시스템만 접속이 안 됩니다.”
“어제까지 되던 서비스가 오늘은 안 열립니다.”
“서버는 켜져 있는데 왜 접속이 안 되는 건가요?”

처음에는 서버 장애처럼 보이지만, 실제로는 서버 전원이나 OS 문제가 아니라 웹서버, WAS, 서비스 포트, 방화벽, DNS, 인증서, 애플리케이션 오류 등 다른 원인일 수 있습니다.

IT 운영직이나 SM팀 업무에서는 “서버가 켜져 있다”와 “서비스가 정상 접속된다”를 구분해서 봐야 합니다.

이번 글에서는 서버는 켜져 있는데 접속이 안 될 때 IT 운영자가 확인해야 할 항목을 실무 기준으로 정리해보겠습니다.

서버가 켜져 있다는 말의 의미

운영 업무에서 “서버는 켜져 있다”는 말은 보통 서버 OS가 살아 있다는 의미입니다.

예를 들어 서버에 원격 접속이 가능하거나, 모니터링에서 서버 상태가 UP으로 보이거나, ping 응답이 있을 수 있습니다.

하지만 서버가 켜져 있다고 해서 사용자가 접속하는 업무 시스템이 정상이라는 뜻은 아닙니다.

서버 안에는 여러 서비스가 동작할 수 있습니다.

• 웹서버
• WAS
• DB 연결 모듈
• 배치 프로그램
• SFTP 서비스
• API 서비스
• 백그라운드 프로세스
• 로그 수집 서비스

서버 OS는 정상이어도 웹서버나 WAS가 내려가 있으면 사용자는 화면에 접속할 수 없습니다.

또 서비스는 떠 있어도 방화벽이나 포트가 막혀 있으면 외부에서는 접속할 수 없습니다.

그래서 운영자는 서버 상태와 서비스 상태를 따로 확인해야 합니다.

접속 장애가 발생하는 대표적인 원인

서버는 켜져 있지만 접속이 안 되는 원인은 다양합니다.

대표적인 원인은 다음과 같습니다.

• 웹서버 또는 WAS가 내려감
• 서비스 포트가 열려 있지 않음
• 방화벽에서 접속이 차단됨
• DNS가 잘못된 IP를 바라봄
• 도메인 변경 후 반영이 안 됨
• SSL 인증서 오류 발생
• 서버 리소스 부족으로 응답 지연
• 애플리케이션 오류 발생
• DB 연결 실패
• 로드밸런서 또는 프록시 설정 문제
• 특정 사용자 네트워크 문제
• VPN 또는 내부망 접근 문제
• 배포 후 서비스 재기동 누락

사용자 입장에서는 모두 “접속이 안 된다”로 보입니다.

하지만 운영자 입장에서는 어느 구간에서 막혔는지 하나씩 분리해서 확인해야 합니다.

1. 특정 사용자만 안 되는지 전체가 안 되는지 확인

가장 먼저 확인해야 할 것은 영향 범위입니다.

특정 사용자 한 명만 접속이 안 되는지, 전체 사용자가 모두 접속하지 못하는지에 따라 확인 방향이 달라집니다.

확인해야 할 항목은 다음과 같습니다.

• 특정 사용자만 발생하는지
• 특정 PC에서만 발생하는지
• 특정 부서나 지점에서만 발생하는지
• 사내망에서는 되는지
• 외부망에서는 되는지
• VPN 접속자만 안 되는지
• 전체 사용자가 동시에 안 되는지
• 특정 시간대에만 발생하는지

특정 사용자만 안 된다면 사용자 PC, 브라우저, 네트워크, VPN, 권한 문제일 가능성이 있습니다.

반대로 전체 사용자가 모두 안 된다면 서버 서비스, 네트워크, 방화벽, DNS, 로드밸런서, 애플리케이션 장애 가능성이 더 큽니다.

운영자는 장애 접수 직후 영향 범위를 먼저 확인해야 합니다.

2. 접속 주소가 맞는지 확인

접속 장애가 발생하면 사용자가 접속한 주소를 정확히 확인해야 합니다.

사용자는 “주소는 맞다”고 말하지만 실제로는 예전 주소, 잘못된 링크, 오타가 있는 URL을 사용할 수 있습니다.

확인해야 할 항목은 다음과 같습니다.

• 사용자가 접속한 전체 URL
• http와 https 구분
• 도메인 오타 여부
• www 포함 여부
• 포트 번호 포함 여부
• 접속 경로가 맞는지
• 예전 즐겨찾기 주소인지
• 공지나 메일에 잘못된 링크가 공유된 것은 아닌지

예를 들어 아래 두 주소는 비슷해 보이지만 서로 다른 결과가 나올 수 있습니다.

https://example.com
https://www.example.com

또 서버 이전이나 시스템 개편 후 기존 주소를 계속 사용하면 404 오류나 접속 실패가 발생할 수 있습니다.

운영자는 사용자가 실제로 어느 주소로 접속했는지 먼저 확인해야 합니다.

3. 도메인이 올바른 IP를 바라보는지 확인

도메인으로 접속하는 시스템이라면 DNS 확인이 필요합니다.

서버가 정상이어도 도메인이 잘못된 IP를 바라보고 있으면 사용자는 접속할 수 없습니다.

도메인 확인은 nslookup 명령어로 할 수 있습니다.

nslookup example.com

확인해야 할 항목은 다음과 같습니다.

• 도메인이 정상 조회되는지
• 조회된 IP가 운영 서버 IP와 맞는지
• 기존 서버 IP를 바라보고 있지 않은지
• 테스트 서버 IP를 바라보고 있지 않은지
• 내부망과 외부망에서 조회 결과가 다른지
• DNS 변경 후 캐시가 남아 있지 않은지

특히 서버 이전이나 도메인 변경 후에는 DNS 문제가 자주 발생할 수 있습니다.

사용자는 같은 도메인으로 접속하지만, 실제로는 잘못된 서버나 예전 서버로 연결되고 있을 수 있습니다.

4. 서버 IP로 기본 통신이 되는지 확인

도메인이 올바른 IP를 바라보고 있다면 서버 IP로 기본 통신이 되는지 확인할 수 있습니다.

이때 사용할 수 있는 명령어가 ping입니다.

ping 192.168.0.10

ping 응답이 있으면 기본적인 네트워크 통신은 되는 상태로 볼 수 있습니다.

하지만 ping 결과를 해석할 때는 주의해야 합니다.

ping이 된다고 해서 서비스 접속이 정상이라는 뜻은 아닙니다.

ping은 서버 IP까지 기본 통신이 되는지 확인하는 것이고, 실제 웹 서비스 접속은 80, 443 같은 포트가 열려 있어야 합니다.

또 보안 정책상 ping 응답을 차단한 서버도 있습니다.

따라서 ping은 참고용으로 보고, 서비스 포트 확인까지 함께 해야 합니다.

5. 서비스 포트가 열려 있는지 확인

서버는 켜져 있어도 사용자가 접속하는 서비스 포트가 막혀 있으면 화면은 열리지 않습니다.

웹 시스템은 보통 80 또는 443 포트를 사용합니다.

HTTPS 접속 확인은 아래처럼 할 수 있습니다.

telnet example.com 443

Windows PowerShell에서는 아래 명령어를 사용할 수 있습니다.

Test-NetConnection example.com -Port 443

확인해야 할 항목은 다음과 같습니다.

• 80 또는 443 포트가 열려 있는지
• 실제 서비스 포트가 무엇인지
• 서버에서 해당 포트가 LISTEN 상태인지
• 방화벽에서 해당 포트를 허용하는지
• 로드밸런서나 프록시에서 포트가 정상 연결되는지
• 운영 환경과 테스트 환경 포트를 혼동하지 않았는지

포트 접속이 실패한다면 방화벽, 서비스 미기동, 네트워크 경로 문제를 의심할 수 있습니다.

포트 접속은 성공하는데 화면이 안 열린다면 애플리케이션, 인증, 권한, 내부 오류를 추가로 확인해야 합니다.

6. 웹서버와 WAS가 정상 기동 중인지 확인

서버 OS가 살아 있어도 웹서버나 WAS가 내려가 있으면 사용자는 시스템에 접속할 수 없습니다.

업무 시스템에서는 보통 웹서버와 WAS가 함께 동작합니다.

웹서버는 사용자의 요청을 받고, WAS는 실제 업무 로직을 처리하는 역할을 합니다.

확인해야 할 항목은 다음과 같습니다.

• 웹서버가 기동 중인지
• WAS가 기동 중인지
• 서비스 프로세스가 살아 있는지
• 최근 서비스 재기동 이력이 있는지
• 배포 후 재기동이 정상 완료되었는지
• 특정 포트가 LISTEN 상태인지
• 서비스 로그에 오류가 있는지

예를 들어 서버는 켜져 있지만 WAS가 내려가 있으면 503 오류가 발생할 수 있습니다.

또 웹서버는 정상인데 WAS 연결이 끊어져 있으면 화면이 열리지 않거나 일부 기능만 실패할 수 있습니다.

운영자는 서버 OS 상태와 애플리케이션 서비스 상태를 구분해서 확인해야 합니다.

7. 방화벽에서 차단되고 있지 않은지 확인

서버와 서비스가 정상이어도 방화벽에서 통신이 차단되면 사용자는 접속할 수 없습니다.

특히 신규 시스템 오픈, 서버 이전, IP 변경, 외부 업체 연동, VPN 접속에서는 방화벽 확인이 중요합니다.

확인해야 할 항목은 다음과 같습니다.

• 출발지 IP
• 목적지 IP
• 목적지 포트
• 접속 방향
• Inbound 또는 Outbound 여부
• 방화벽 정책 등록 여부
• 최근 방화벽 정책 변경 여부
• 서버 IP 변경 후 방화벽 반영 여부
• 특정 네트워크 대역만 차단되는지

예를 들어 사내망에서는 접속되는데 외부망에서는 접속이 안 된다면 외부망 방화벽 정책을 확인해야 합니다.

VPN 사용자만 접속이 안 된다면 VPN IP 대역이 해당 서버 방화벽에 허용되어 있는지 확인해야 합니다.

방화벽 문제는 서버가 정상이어도 접속 장애처럼 보일 수 있습니다.

8. 서버 리소스 상태 확인

서버가 켜져 있고 서비스도 살아 있지만 응답이 너무 느리거나 접속이 실패한다면 서버 리소스 상태를 확인해야 합니다.

확인해야 할 항목은 다음과 같습니다.

• CPU 사용률
• 메모리 사용률
• 디스크 사용률
• 네트워크 사용량
• 프로세스 수
• 파일 핸들 또는 세션 수
• WAS Thread 상태
• DB Connection Pool 상태

예를 들어 메모리가 부족하거나 CPU가 과도하게 사용 중이면 서버가 요청에 정상적으로 응답하지 못할 수 있습니다.

디스크가 가득 차면 로그를 쓰지 못하거나 임시 파일 생성이 실패해서 서비스 오류가 발생할 수도 있습니다.

운영자는 접속 장애가 발생했을 때 단순히 서비스 기동 여부만 보지 말고 리소스 상태도 함께 확인해야 합니다.

9. 애플리케이션 로그 확인

서버와 포트가 정상이어도 애플리케이션 내부 오류로 접속이 실패할 수 있습니다.

이때는 로그를 확인해야 합니다.

확인해야 할 로그는 다음과 같습니다.

• 웹서버 access log
• 웹서버 error log
• WAS 로그
• 애플리케이션 로그
• 배포 로그
• DB 연결 로그
• 인증 로그
• API 호출 로그

로그에서 확인해야 할 항목은 다음과 같습니다.

• 오류 발생 시간
• 요청 URL
• 응답 코드
• 사용자 IP
• 사용자 ID
• Exception 메시지
• DB connection 오류
• Timeout 메시지
• 500 또는 503 오류 여부

예를 들어 사용자는 “접속이 안 된다”고 말하지만 로그를 보면 실제로는 500 오류가 발생하고 있을 수 있습니다.

또는 503 오류가 반복된다면 WAS 서비스나 서버 부하 문제를 의심할 수 있습니다.

10. DB 연결 상태 확인

업무 시스템은 대부분 DB와 연결되어 동작합니다.

서버와 웹서비스가 정상이어도 DB 연결이 실패하면 화면이 열리지 않거나 로그인 이후 기능이 동작하지 않을 수 있습니다.

확인해야 할 항목은 다음과 같습니다.

• DB 서버가 정상인지
• DB 포트 접속이 가능한지
• DB 리스너가 기동 중인지
• DB 계정이 정상인지
• DB connection pool이 가득 차지 않았는지
• 장시간 실행 중인 쿼리가 있는지
• DB 부하가 높은지
• 최근 DB 작업이나 패치가 있었는지

예를 들어 로그인 화면은 열리지만 로그인 후 계속 오류가 발생한다면 DB 조회나 인증 데이터 접근 문제일 수 있습니다.

DB connection failed, DB timeout 같은 로그가 있다면 DB 연결 상태를 확인해야 합니다.

11. 로드밸런서와 프록시 확인

운영 환경에서는 사용자가 직접 WAS 서버에 접속하지 않고 로드밸런서나 프록시를 거치는 경우가 많습니다.

이 경우 서버 한 대는 정상이지만 로드밸런서 설정 문제로 접속이 실패할 수 있습니다.

확인해야 할 항목은 다음과 같습니다.

• 로드밸런서 상태
• 대상 서버 헬스체크 상태
• 일부 서버만 장애인지
• 프록시 설정이 정상인지
• SSL 인증서가 로드밸런서에 정상 적용되어 있는지
• URL Rewrite 설정이 정상인지
• 세션 유지 설정이 필요한지
• 최근 네트워크 장비 작업이 있었는지

로드밸런서 뒤에 서버가 여러 대라면 일부 서버만 장애가 발생해도 사용자는 간헐적으로 접속 실패를 경험할 수 있습니다.

운영자는 서버 한 대만 확인하지 말고 전체 서비스 경로를 확인해야 합니다.

12. SSL 인증서 확인

HTTPS 접속 장애에서는 SSL 인증서도 확인해야 합니다.

서버는 정상이고 포트도 열려 있지만 인증서 문제가 있으면 브라우저에서 보안 경고가 발생하거나 접속이 차단될 수 있습니다.

확인해야 할 항목은 다음과 같습니다.

• 인증서 만료 여부
• 인증서 도메인 일치 여부
• 중간 인증서 정상 여부
• 인증서 갱신 후 서버 반영 여부
• 로드밸런서나 웹서버에 인증서가 정상 적용되었는지
• http에서 https로 리다이렉트가 정상인지

예를 들어 인증서는 www.example.com 기준인데 사용자는 example.com으로 접속하면 인증서 경고가 발생할 수 있습니다.

또 인증서 갱신 후 웹서버 재기동이 누락되면 여전히 기존 인증서가 적용되어 있을 수 있습니다.

서버는 켜져 있는데 접속이 안 될 때 확인 순서

서버는 켜져 있는데 사용자가 접속하지 못한다면 아래 순서로 확인하면 좋습니다.

1. 특정 사용자 문제인지 전체 사용자 문제인지 확인
2. 사용자가 접속한 URL 확인
3. 도메인이 올바른 IP를 바라보는지 확인
4. 서버 IP로 기본 통신이 되는지 확인
5. 서비스 포트가 열려 있는지 확인
6. 웹서버와 WAS가 기동 중인지 확인
7. 방화벽에서 차단되지 않았는지 확인
8. 서버 리소스 상태 확인
9. 애플리케이션 로그 확인
10. DB 연결 상태 확인
11. 로드밸런서와 프록시 상태 확인
12. SSL 인증서 상태 확인
13. 최근 배포나 설정 변경 여부 확인
14. 조치 후 정상 접속 여부 확인
15. 장애 이력 기록

이 순서대로 확인하면 단순히 “서버는 살아 있다”에서 멈추지 않고, 실제 서비스 접속이 왜 안 되는지 원인을 좁힐 수 있습니다.

사용자에게 안내할 때는 어떻게 말할까?

접속 장애가 발생했을 때 사용자에게는 너무 기술적인 설명보다 현재 확인 중인 범위를 간단히 안내하는 것이 좋습니다.

전체 장애라면 이렇게 안내할 수 있습니다.

현재 업무 시스템 접속 장애가 확인되어 서버 및 서비스 상태를 점검 중입니다. 원인 확인 후 조치 결과를 다시 안내드리겠습니다.

특정 사용자 문제라면 이렇게 안내할 수 있습니다.

현재 다른 사용자 접속은 정상으로 확인되며, 해당 PC 또는 네트워크 환경에서의 접속 문제로 보입니다. 브라우저 캐시 삭제 및 다른 네트워크 환경에서 재확인 부탁드립니다.

방화벽 문제라면 이렇게 안내할 수 있습니다.

서버 상태는 정상이나 접속 경로상 방화벽 정책 확인이 필요하여 네트워크 담당자에게 확인 요청 중입니다. 조치 완료 후 정상 접속 여부를 다시 안내드리겠습니다.

서비스 재기동이 필요한 경우라면 이렇게 안내할 수 있습니다.

서버는 정상이나 애플리케이션 서비스 응답 오류가 확인되어 서비스 재기동 및 로그 확인을 진행 중입니다.

운영자는 사용자가 기다려야 하는지, 재접속을 하면 되는지, 추가 확인이 필요한지 명확히 안내해야 합니다.

네트워크 담당자에게 전달할 정보

네트워크나 방화벽 문제가 의심될 때는 필요한 정보를 정리해서 전달해야 합니다.

전달하면 좋은 항목은 다음과 같습니다.

• 장애 발생 시간
• 사용자 접속 환경
• 출발지 IP
• 목적지 도메인 또는 IP
• 목적지 포트
• 접속 URL
• ping 결과
• telnet 또는 Test-NetConnection 결과
• nslookup 결과
• 특정 사용자 또는 전체 사용자 여부
• 최근 서버 이전 또는 정책 변경 여부

예를 들어 다음과 같이 전달할 수 있습니다.

장애 발생 시간: 2026-06-20 10:30
증상: 업무 시스템 접속 불가
출발지: 사내망 사용자 PC
목적지: example.com
목적지 포트: 443
nslookup 결과: 123.123.123.123
Test-NetConnection 결과: TcpTestSucceeded False
확인 요청: 해당 구간 방화벽 및 네트워크 경로 확인 필요

이렇게 정리하면 네트워크 담당자가 확인할 범위를 빠르게 파악할 수 있습니다.

개발자나 외부 업체에 전달할 정보

서버와 네트워크는 정상인데 애플리케이션 오류가 의심된다면 개발자나 외부 업체에 확인 요청이 필요합니다.

전달하면 좋은 항목은 다음과 같습니다.

• 오류 발생 시간
• 접속 URL
• 사용자 ID
• 오류 화면 캡처
• 응답 코드
• 로그 메시지
• 재현 가능 여부
• 최근 배포 여부
• 특정 사용자 또는 전체 사용자 여부
• 서버 리소스 상태
• DB 연결 오류 여부

예를 들어 다음과 같이 전달할 수 있습니다.

금일 11:10경 업무 시스템 접속 시 500 오류가 발생했습니다.
서버 포트 접속은 정상이며, WAS 로그에서 DB connection timeout 메시지가 확인됩니다.
최근 배포 이후 발생한 것으로 보여 DB 연결 설정 및 애플리케이션 로그 확인 부탁드립니다.

이렇게 전달하면 개발자나 외부 업체가 원인을 더 빠르게 확인할 수 있습니다.

접속 장애 대응 시 주의할 점

서버 접속 장애를 처리할 때는 몇 가지 주의할 점이 있습니다.

첫 번째, 서버가 켜져 있다고 해서 정상으로 판단하지 않아야 합니다.

서비스, 포트, 로그, DB 연결까지 확인해야 실제 서비스 상태를 알 수 있습니다.

두 번째, 특정 사용자 문제와 전체 장애를 구분해야 합니다.

영향 범위를 먼저 확인해야 불필요한 장애 확대를 줄일 수 있습니다.

세 번째, 네트워크와 애플리케이션 문제를 구분해야 합니다.

포트 접속이 안 되면 네트워크나 방화벽을 먼저 확인하고, 포트 접속은 되는데 오류가 발생하면 애플리케이션 로그를 확인해야 합니다.

네 번째, 최근 변경사항을 반드시 확인해야 합니다.

배포, 서버 재기동, 방화벽 변경, DNS 변경, 인증서 갱신, DB 작업 이후 장애가 발생하는 경우가 많습니다.

다섯 번째, 조치 이력을 남겨야 합니다.

접속 장애는 반복될 수 있기 때문에 발생 시간, 원인, 조치 방법, 담당자를 기록해두는 것이 좋습니다.

IT 운영자가 이 흐름을 알아야 하는 이유

IT 운영자는 모든 장애를 직접 개발해서 수정하는 사람이 아닐 수 있습니다.

하지만 장애가 발생했을 때 문제 위치를 빠르게 좁히고, 정확한 담당자에게 전달해야 합니다.

서버는 켜져 있는데 접속이 안 되는 상황을 이해하면 다음을 구분할 수 있습니다.

• 서버 OS 문제인지
• 웹서버나 WAS 문제인지
• 포트나 방화벽 문제인지
• DNS 문제인지
• 인증서 문제인지
• DB 연결 문제인지
• 로드밸런서 문제인지
• 사용자 PC 문제인지
• 애플리케이션 오류인지

이 차이를 구분할 수 있어야 장애 대응 시간이 줄어듭니다.

운영 업무에서는 “서버가 살아 있다”는 말에서 끝나는 것이 아니라, 사용자가 실제로 서비스를 이용할 수 있는지까지 확인해야 합니다.

마무리

서버는 켜져 있는데 접속이 안 되는 상황은 IT 운영 업무에서 자주 발생합니다.

이때 서버 전원이나 OS 상태만 확인하고 정상이라고 판단하면 안 됩니다.

사용자 접속 URL, DNS, ping, 포트, 방화벽, 웹서버, WAS, 서버 리소스, 애플리케이션 로그, DB 연결, 로드밸런서, SSL 인증서까지 단계적으로 확인해야 합니다.

특히 서버가 정상이어도 서비스 포트가 막혀 있거나, WAS가 내려가 있거나, DB 연결이 실패하거나, DNS가 잘못된 IP를 바라보면 사용자는 시스템에 접속할 수 없습니다.

IT 운영직이나 SM팀 업무를 준비하고 있다면 “서버 상태”와 “서비스 접속 상태”를 구분하는 습관을 들이는 것이 좋습니다.

이 차이를 이해하면 장애 대응 시 원인을 훨씬 빠르게 좁힐 수 있습니다.

다음 글에서는 접속 장애와 함께 자주 문의되는 시스템이 느릴 때 확인해야 할 서버·DB·네트워크 점검 순서를 정리해보겠습니다.

---

함께 보면 좋은 글

• DNS 오류와 도메인 접속 장애 확인 방법｜IT 운영자가 먼저 봐야 할 네트워크 기본
• Connection timeout 오류 원인과 확인 방법｜IT 운영자가 먼저 봐야 할 네트워크·서버 문제
• ping, telnet, nslookup 차이｜IT 운영자가 장애 확인할 때 쓰는 네트워크 명령어
• 포트가 막혔다는 건 무슨 뜻일까?｜IT 운영자가 알아야 할 방화벽 기본
• IT 운영자가 네트워크를 알아야 하는 이유｜장애 대응에 필요한 기본 개념