로컬 웹 서비스가 열리지 않을 때 포트·프로세스부터 확인하는 복구 절차

로컬 웹 서비스가 열리지 않을 때 포트·프로세스부터 확인하는 복구 절차

브라우저가 로컬 주소를 열지 못하고 즉시 연결을 거절한다면, 새로고침보다 먼저 서버가 실제로 요청을 받고 있는지 확인해야 합니다. 화면에는 단순한 접속 실패처럼 보이지만, 실행 프로세스가 멈췄는지·포트가 다른 프로그램에 잡혔는지·외부 접근 범위가 제한됐는지에 따라 조치가 달라집니다. 캐시 삭제나 브라우저 교체는 마지막 단계로 두고, 실행 창의 로그와 포트 상태를 먼저 대조하는 편이 빠릅니다. 특히 개발 서버, 사내 도구, NAS 관리 화면, 테스트용 웹 서비스는 재시작만 반복하면 기존 원인을 놓치기 쉽습니다. 오류 화면을 유지한 상태에서 서비스 종류와 주소를 확인해 두면 원격 점검도 훨씬 정확해집니다. 초기 확인이 어렵다면 동네형컴퓨터 010-6833-8119 로 증상을 전달해 순서를 잡을 수 있습니다.

수신 포트와 서비스 프로세스 상태

가장 먼저 볼 항목은 웹 서버 프로세스입니다. 서버 실행 명령을 눌렀더라도 시작 직후 오류로 종료되면, 브라우저가 연결할 대상 자체가 없습니다. 작업 관리자에서 해당 프로그램이 남아 있는지, Windows 서비스 목록에서 관련 서비스가 실행 중인지, 터미널 창에 종료 문구가 없는지를 함께 확인합니다.

브라우저에서 하면 STATUS_CONNECTION_REFUSED가 나타나는 경우에도 주소만 바꾸기 전에 서비스가 지정 포트를 수신 중인지부터 봐야 합니다. 명령 프롬프트에서 netstat -ano | findstr :포트번호를 실행하면 해당 포트를 사용하는 PID를 확인할 수 있습니다. 예를 들어 서비스 설정이 8080 포트인데 목록에 아무 결과가 없다면 서버가 열리지 않은 상태일 가능성이 큽니다.

반대로 포트가 보이는데 웹 화면이 기대와 다르면 PID와 프로세스 이름을 대조합니다. 이전에 실행한 개발 서버, Docker 컨테이너, 데이터베이스 관리 도구, 다른 웹 프로그램이 같은 포트를 점유할 수 있습니다. 이때 무작정 종료하기보다 현재 포트를 듣는 프로그램이 무엇인지 확인한 뒤, 필요한 서비스라면 포트를 변경하고 불필요한 프로세스라면 정상 종료하는 방식이 안전합니다.

바인딩 주소·프록시·방화벽 충돌

서버가 실행 중이고 포트도 열려 있다면, 다음은 어느 주소에서 요청을 받도록 설정됐는지 확인할 차례입니다. 127.0.0.1 또는 localhost에만 바인딩된 서비스는 같은 PC에서는 열리지만 다른 PC나 휴대폰에서는 접속되지 않습니다. 내부망에서 사용해야 한다면 서비스 설정의 host 값, PC의 내부 IP, 네트워크 프로필을 함께 확인해야 합니다.

localhost는 열리는데 127.0.0.1이 다르거나 반대 결과가 나오면 hosts 파일, 프록시 프로그램, 보안 모듈의 개입을 살핍니다. 브라우저 프록시가 켜져 있으면 로컬 요청까지 우회하거나 차단할 수 있으며, 일부 보안 프로그램은 지정되지 않은 포트의 수신 연결을 막습니다. 이 경우 브라우저 캐시를 비우는 것보다 프록시 예외 목록과 보안 정책을 점검하는 편이 직접적입니다.

다른 기기에서 접속해야 한다면 Windows 방화벽의 인바운드 규칙도 확인합니다. 서버 프로그램 자체를 허용했는지, 사용하는 TCP 포트가 허용됐는지, 현재 네트워크가 공용으로 분류돼 있지는 않은지를 구분합니다. 포트를 열기 전에는 서비스가 외부 공개 대상인지 먼저 판단해야 하며, 테스트 목적이라면 필요한 내부망 범위로만 제한하는 것이 좋습니다.

실행 실패를 줄이는 재기동 순서

반복 재시작은 간단해 보여도 포트 충돌과 설정 오류를 가릴 수 있습니다. 먼저 서버를 정상 종료하고, 포트 조회 명령으로 기존 PID가 사라졌는지 확인합니다. 남아 있는 프로세스가 있다면 어떤 프로그램인지 판별한 뒤 종료 여부를 결정합니다. 그 다음 설정 파일의 포트 번호, host 또는 bind 주소, 환경 변수, 프록시 관련 값을 확인하고 서버를 한 번만 다시 시작합니다.

재실행 후에는 콘솔 로그의 시작 완료 문구와 브라우저 오류가 발생한 시점을 비교합니다. “address already in use”, “permission denied”, “bind failed”처럼 시작 단계에서 나온 문구는 포트·권한·주소 설정에 바로 연결됩니다. 반면 서버가 정상 시작됐는데도 브라우저에서 하면 STATUS_CONNECTION_REFUSED가 계속된다면 접속 주소 오입력, 프록시, 방화벽 또는 다른 네트워크 경로를 우선 의심할 수 있습니다.

관리자 권한이 필요한 포트나 서비스 등록형 프로그램은 실행 권한도 확인합니다. 다만 관리자 실행만으로 해결하려 하지 말고, 로그가 가리키는 권한 경로와 계정 권한을 확인해야 재발을 줄일 수 있습니다. 개발 도구를 업데이트한 직후 발생했다면 런타임 버전, 플러그인, 기존 설정 파일의 호환 여부도 함께 검토합니다.

오류 화면을 유지한 상태로 작업 일정 조율

원격 점검 전에는 서버 실행 창을 닫지 말고, 브라우저 주소 표시줄과 오류 화면도 그대로 둡니다. 접속 주소, 포트 번호, 오류가 난 시각, 같은 PC에서의 접속 여부만 있어도 프로세스 문제와 네트워크 범위를 상당 부분 나눌 수 있습니다. 원격 작업은 새벽 시간을 제외하고 조율 가능하며, 현장 확인이 필요한 경우 출장 작업은 09:00~18:00 사이 서울·경기·인천·세종 일정으로 안내합니다.

로그가 남아 있을 때 문의하기

서비스를 여러 번 켰다 끄기 전에 오류 정보를 확보하는 것이 중요합니다. 준비하면 좋은 항목은 브라우저 오류 화면, 실행한 서비스나 개발 도구의 이름과 버전, 실행 로그 앞뒤 일부, 사용하려는 주소와 포트 번호입니다. 외부 기기에서도 안 열리는지, 해당 PC에서만 안 열리는지도 함께 적으면 바인딩 문제와 방화벽 문제를 빠르게 분리할 수 있습니다.

동네형컴퓨터는 로그와 포트 상태를 기준으로 실행 실패 원인을 정리하고, 필요한 경우 설정 수정과 재기동 순서까지 안내합니다. 문의는 010-6833-8119 또는 https://udns.kr/에서 남길 수 있습니다.

포트와 프로세스를 확인해 재발을 줄이는 마무리

로컬 웹 서비스의 접속 거절은 브라우저 자체보다 서버가 포트를 듣지 못하는 상황에서 시작되는 경우가 많습니다. 프로세스 실행 여부와 포트 점유 PID를 먼저 확인하면 불필요한 재설치를 줄일 수 있습니다.

그 다음에는 localhost, 127.0.0.1, 내부 IP의 결과를 비교해 바인딩 범위를 판단하고, 프록시와 방화벽 규칙을 포트 기준으로 검토합니다. 한 가지 조치 뒤에는 반드시 로그와 접속 결과가 어떻게 바뀌었는지 기록하는 것이 좋습니다.

오류 화면과 실행 로그를 함께 남겨 두면 다음 장애 때도 원인을 더 빨리 좁힐 수 있습니다. 포트·프로세스·주소 설정을 분리해서 확인하는 순서가 가장 안정적인 복구 기준입니다.

자주 묻는 질문

Q. 접속 거절 오류는 무엇을 뜻하나요?

A. 요청한 주소와 포트에서 연결을 받아 주는 서비스가 없거나, 중간 설정이 연결을 차단하고 있다는 뜻입니다. 서버 미실행, 포트 충돌, 바인딩 주소 제한, 방화벽 또는 프록시 설정을 차례로 확인합니다.

Q. 포트가 이미 사용 중인지 어떻게 확인하나요?

A. Windows 명령 프롬프트에서 netstat -ano | findstr :포트번호를 실행하면 점유 여부와 PID를 볼 수 있습니다. PID를 작업 관리자 세부 정보 탭에서 찾아 어떤 프로그램인지 대조하면 됩니다.

Q. 원격 점검으로 해결 가능한 범위는 어디까지인가요?

A. 서버 실행 상태, 포트 점유, 설정 파일의 주소·포트 값, 프록시·방화벽 기본 점검, 로그 분석은 원격으로 확인할 수 있습니다. 장비 전원, 공유기 연결, 사내 보안 정책처럼 현장 확인이 필요한 항목은 증상에 따라 별도 판단합니다.