본문 바로가기

카테고리 없음

리눅스 서버 네트워크 연결 확인법: ping, curl, ss 명령어 활용하기

 

리눅스 서버를 운영하다 보면 웹사이트가 갑자기 접속되지 않거나 다른 서버와 통신이 되지 않는 문제가 발생할 수 있습니다.

이때 무작정 서버를 재부팅하기보다는 네트워크 연결 상태를 단계별로 확인하는 것이 중요합니다.

리눅스에서는 별도의 프로그램을 설치하지 않아도 기본적인 네트워크 상태를 확인할 수 있는 다양한 명령어가 있습니다.

그중에서도 실무에서 자주 사용하는 명령어가 바로 **ping, curl, ss**입니다.

ping은 서버 간 기본적인 통신이 가능한지 확인할 때 사용하고, curl은 웹서버와 HTTP/HTTPS 통신이 정상적으로 이루어지는지 확인할 때 유용합니다.

ss는 현재 서버에서 어떤 포트가 열려 있고 어떤 네트워크 연결이 이루어지고 있는지 확인하는 데 사용합니다.

이번 글에서는 리눅스 서버 네트워크 연결 확인 방법을 초보자도 쉽게 따라 할 수 있도록 ping, curl, ss 명령어를 중심으로 알아보겠습니다.


1. 리눅스 서버 네트워크 문제는 단계적

으로 확인해야 한다

서버에 접속이 안 된다고 해서 반드시 인터넷 자체에 문제가 있는 것은 아닙니다.

예를 들어 다음과 같은 다양한 원인이 있을 수 있습니다.

  • 서버의 네트워크 인터페이스 문제
  • DNS 설정 문제
  • 방화벽 차단
  • 특정 포트 미개방
  • 웹서버 프로세스 중지
  • 애플리케이션 오류
  • 원격 서버 장애
  • 잘못된 라우팅 설정

따라서 네트워크 장애가 발생하면 다음과 같이 단계적으로 확인하는 것이 좋습니다.

네트워크 연결
      ↓
ping
      ↓
DNS 및 웹 통신
      ↓
curl
      ↓
포트 및 소켓 상태
      ↓
ss
      ↓
방화벽 및 서비스 설정 확인

이러한 순서로 점검하면 문제의 범위를 빠르게 좁힐 수 있습니다.


2. ping 명령어란?

ping은 네트워크에서 가장 기본적으로 사용하는 연결 확인 명령어입니다.

특정 서버에 패킷을 보내고 응답이 돌아오는지 확인하여 네트워크 통신 상태를 점검할 수 있습니다.

기본적인 사용법은 다음과 같습니다.

ping 8.8.8.8

또는 도메인 이름으로 테스트할 수도 있습니다.

ping google.com

정상적으로 통신된다면 다음과 비슷한 결과가 나타납니다.

64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=20.5 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=19.8 ms

여기서 time은 응답이 돌아오는 데 걸린 시간을 의미합니다.


3. ping 결과를 어떻게 해석할까?

ping 결과에서 자주 확인하는 항목은 다음과 같습니다.

time

time=20.5 ms

요청을 보내고 응답을 받는 데 걸린 시간입니다.

일반적으로 숫자가 낮을수록 네트워크 응답 속도가 빠르다고 볼 수 있습니다.

packet loss

ping을 여러 번 실행하면 패킷 손실률도 확인할 수 있습니다.

예를 들어:

5 packets transmitted, 5 received, 0% packet loss

0% packet loss라면 테스트 과정에서 패킷 손실이 없었다는 의미입니다.

반대로:

5 packets transmitted, 3 received, 40% packet loss

라면 패킷 손실이 발생하고 있다는 의미이므로 네트워크 상태를 추가로 확인해야 합니다.


4. ping을 계속 실행하지 않는 방법

리눅스의 ping은 기본적으로 계속 실행되는 환경이 많습니다.

몇 번만 테스트하고 싶다면 -c 옵션을 사용할 수 있습니다.

ping -c 4 8.8.8.8

위 명령은 총 4번 패킷을 전송하고 종료합니다.

서버 장애를 확인할 때 다음과 같이 사용하는 것도 편리합니다.

ping -c 4 192.168.1.1

5. ping이 안 된다고 인터넷이 반드시 끊긴 것은 아니다

여기서 중요한 점이 있습니다.

ping에 응답이 없다고 해서 반드시 서버가 네트워크에 연결되지 않은 것은 아닙니다.

일부 서버나 방화벽은 보안상의 이유로 ICMP 패킷에 응답하지 않도록 설정되어 있을 수 있습니다.

예를 들어:

ping example.com

에서 응답이 없더라도 웹사이트가 정상적으로 접속되는 경우가 있습니다.

따라서 ping만으로 네트워크 상태를 판단해서는 안 됩니다.

이때 사용하는 것이 curl입니다.


6. curl 명령어란?

curl은 서버에서 HTTP, HTTPS 등의 네트워크 요청을 보내고 응답을 확인할 때 사용하는 명령어입니다.

웹서버가 실제로 응답하고 있는지 확인할 때 특히 유용합니다.

예를 들어:

curl https://example.com

웹페이지의 응답 내용이 출력되면 해당 웹서버와 HTTP/HTTPS 통신이 이루어지고 있다는 의미입니다.


7. 웹사이트 응답 헤더만 확인하기

웹페이지의 전체 내용을 확인할 필요가 없다면 -I 옵션을 사용할 수 있습니다.

curl -I https://example.com

정상적인 웹서버라면 다음과 비슷한 응답이 나올 수 있습니다.

HTTP/2 200
content-type: text/html
server: nginx

여기서 중요한 부분은 HTTP 상태 코드입니다.


8. curl HTTP 상태 코드 이해하기

200 OK

HTTP/2 200

요청이 정상적으로 처리됐다는 의미입니다.

301 또는 302

다른 주소로 이동시키는 리다이렉션입니다.

HTTP/2 301

HTTP에서 HTTPS로 이동하도록 설정했을 때 자주 볼 수 있습니다.

403 Forbidden

HTTP/2 403

서버가 요청을 이해했지만 접근을 허용하지 않는 상황입니다.

권한이나 웹서버 설정 등을 확인해야 합니다.

404 Not Found

HTTP/2 404

요청한 페이지나 파일을 찾을 수 없다는 의미입니다.

500 Internal Server Error

HTTP/2 500

서버 내부에서 오류가 발생한 경우 나타날 수 있습니다.

502 Bad Gateway

HTTP/2 502

Nginx와 같은 프록시 서버가 뒤쪽 애플리케이션 서버로부터 정상적인 응답을 받지 못할 때 발생할 수 있습니다.


9. curl로 응답 시간 확인하기

웹사이트가 느린 경우에는 curl을 이용해 응답 시간을 확인할 수도 있습니다.

예를 들어:

curl -o /dev/null -s -w "HTTP: %{http_code}\nTime: %{time_total}s\n" https://example.com

결과는 다음과 비슷하게 나타날 수 있습니다.

HTTP: 200
Time: 0.245s

이 방법을 이용하면 서버에서 특정 웹사이트에 요청했을 때 전체 요청이 완료되는 데 걸리는 시간을 확인할 수 있습니다.


10. 특정 포트가 열려 있는지 확인하기

서버 네트워크 문제에서는 포트 상태도 중요합니다.

예를 들어 웹서버는 일반적으로 HTTP 80번 또는 HTTPS 443번 포트를 사용합니다.

SSH는 일반적으로 22번 포트를 사용합니다.

하지만 실제 서버 환경에서는 포트 번호가 다르게 설정될 수 있으므로 서버 설정을 기준으로 확인해야 합니다.

curl을 이용해 특정 HTTP 포트에 접근할 수도 있습니다.

curl http://127.0.0.1:8080

웹 애플리케이션이 8080 포트에서 실행되고 있다면 해당 포트의 HTTP 응답을 확인할 수 있습니다.


11. ss 명령어란?

ss는 리눅스 서버에서 네트워크 소켓과 연결 상태를 확인하는 명령어입니다.

쉽게 말하면 현재 서버에서 어떤 포트가 열려 있고 어떤 네트워크 연결이 이루어지고 있는지 확인하는 데 사용합니다.

기본 명령어는 다음과 같습니다.

ss

실무에서는 옵션을 함께 사용하는 경우가 많습니다.

ss -tuln

12. ss -tuln 명령어 이해하기

다음 명령어는 서버에서 현재 대기 중인 TCP와 UDP 포트를 확인할 때 매우 유용합니다.

sudo ss -tuln

각 옵션의 의미는 다음과 같습니다.

옵션의미

-t TCP
-u UDP
-l LISTEN 상태
-n 포트와 주소를 숫자로 표시

결과 예시는 다음과 같습니다.

Netid State  Local Address:Port
tcp   LISTEN 0.0.0.0:22
tcp   LISTEN 0.0.0.0:80
tcp   LISTEN 0.0.0.0:443

이 결과를 보면 서버에서 SSH, HTTP, HTTPS 포트가 LISTEN 상태인지 확인할 수 있습니다.


13. 특정 포트만 확인하기

예를 들어 80번 포트가 열려 있는지 확인하려면:

sudo ss -ltnp | grep :80

443번 포트를 확인하려면:

sudo ss -ltnp | grep :443

SSH 포트를 확인하려면:

sudo ss -ltnp | grep :22

이 방법은 웹서버가 실행되고 있는지 확인할 때 매우 유용합니다.


14. 어떤 프로그램이 포트를 사용하는지 확인하기

ss에 -p 옵션을 추가하면 해당 소켓을 사용하는 프로세스 정보를 확인하는 데 도움이 됩니다.

sudo ss -ltnp

예를 들어:

LISTEN 0 511 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=1234,fd=6))

이 결과를 통해 80번 포트를 nginx 프로세스가 사용하고 있다는 것을 확인할 수 있습니다.

웹서버가 정상적으로 실행 중인지 확인할 때 유용한 정보입니다.


15. 현재 연결된 TCP 세션 확인하기

현재 서버의 TCP 연결 상태를 확인하려면 다음 명령어를 사용할 수 있습니다.

ss -ant

좀 더 자세한 프로세스 정보를 확인하려면:

sudo ss -antp

여기서 자주 볼 수 있는 상태가 ESTAB, LISTEN, TIME-WAIT 등입니다.

LISTEN

서버가 특정 포트에서 연결 요청을 기다리는 상태입니다.

ESTAB

연결이 현재 성립되어 통신 중인 상태입니다.

TIME-WAIT

TCP 연결이 종료된 후 일정 시간 동안 유지되는 상태입니다.

웹서버처럼 연결이 많은 서비스에서는 TIME-WAIT가 많이 보일 수도 있으므로 숫자만 보고 무조건 장애라고 판단해서는 안 됩니다.


16. ping, curl, ss의 차이점

세 명령어의 목적을 간단하게 비교하면 다음과 같습니다.

명령어주요 목적

ping 기본적인 네트워크 응답 확인
curl HTTP/HTTPS 웹 통신 확인
ss 서버의 포트와 소켓 연결 상태 확인

쉽게 기억하면 다음과 같습니다.

ping → 서버까지 통신이 되는가?
curl → 웹서비스가 응답하는가?
ss   → 서버의 포트가 열려 있고 연결되고 있는가?

세 명령어를 함께 사용하면 서버 네트워크 장애를 보다 체계적으로 확인할 수 있습니다.


17. 서버가 외부와 통신하지 못할 때 점검 순서

예를 들어 서버에서 외부 웹사이트에 접속할 수 없는 상황이라고 가정해보겠습니다.

먼저 IP 주소로 ping을 테스트합니다.

ping -c 4 8.8.8.8

정상이라면 DNS 문제를 확인하기 위해 도메인으로 테스트합니다.

ping -c 4 example.com

IP 주소는 되는데 도메인 이름이 되지 않는다면 DNS 설정을 확인할 필요가 있습니다.

그다음 실제 HTTPS 통신을 확인합니다.

curl -I https://example.com

이렇게 하면 단순 ICMP 통신뿐만 아니라 실제 웹 통신까지 단계적으로 확인할 수 있습니다.


18. 웹사이트가 접속되지 않을 때 점검 순서

웹사이트가 외부에서 접속되지 않는 상황이라면 서버 내부에서 먼저 확인해볼 수 있습니다.

1단계: 웹서버 포트 확인

sudo ss -ltnp | grep -E ':80|:443'

2단계: 서버 내부에서 웹서비스 요청

curl -I http://127.0.0.1

또는 HTTPS를 사용하는 경우:

curl -Ik https://127.0.0.1

3단계: 외부 도메인 확인

curl -I https://example.com

4단계: 기본 네트워크 확인

ping -c 4 8.8.8.8

이런 순서로 확인하면 문제의 범위를 좁혀갈 수 있습니다.


19. curl과 ss를 함께 사용하면 좋은 이유

예를 들어 Nginx 웹서버가 실행되고 있다고 가정해보겠습니다.

먼저 포트를 확인합니다.

sudo ss -ltnp | grep :80

80번 포트에서 Nginx가 LISTEN 상태라면 서버 내부에서 요청을 보내봅니다.

curl -I http://127.0.0.1

정상적으로 200, 301, 302 등의 응답이 나온다면 웹서버 자체는 요청에 응답하고 있을 가능성이 높습니다.

그런데 외부에서는 접속되지 않는다면 방화벽, 보안 그룹, 네트워크 경로, DNS 등 다른 부분을 확인해야 합니다.


20. 네트워크 명령어만으로 모든 문제를 해결할 수 있는 것은 아니다

ping, curl, ss는 매우 유용하지만 이 세 가지 명령어만으로 모든 네트워크 장애를 해결할 수 있는 것은 아닙니다.

예를 들어 다음과 같은 문제는 추가 확인이 필요합니다.

  • DNS 설정
  • Linux 방화벽
  • 클라우드 보안 그룹
  • 라우팅 테이블
  • 네트워크 인터페이스
  • Nginx 설정
  • Apache 설정
  • 애플리케이션 서버
  • 로드밸런서

따라서 세 명령어를 문제의 원인을 좁히는 기본 진단 도구로 활용하는 것이 좋습니다.


21. 실무에서 자주 사용하는 명령어 정리

ping

ping -c 4 8.8.8.8

서버 간 기본적인 통신 상태를 확인합니다.

curl

curl -I https://example.com

웹서버의 HTTP/HTTPS 응답 상태를 확인합니다.

ss

sudo ss -ltnp

현재 서버에서 LISTEN 중인 TCP 포트와 관련 프로세스를 확인합니다.

특정 포트 확인

sudo ss -ltnp | grep :443

HTTPS 포트 상태를 확인합니다.

로컬 웹서비스 확인

curl -I http://127.0.0.1

서버 내부에서 웹서비스가 응답하는지 확인합니다.


22. 리눅스 서버 네트워크 장애 진단 실전 예제

웹사이트가 접속되지 않는 상황을 가정해보겠습니다.

먼저 서버에 로그인한 후 다음 명령어를 실행합니다.

sudo ss -ltnp | grep -E ':80|:443'

아무 결과가 없다면 웹서버가 해당 포트에서 LISTEN하고 있지 않을 가능성이 있습니다.

다음으로 로컬 요청을 확인합니다.

curl -I http://127.0.0.1

웹서버가 정상적으로 응답하지 않는다면 Nginx나 Apache 상태를 확인해야 합니다.

예를 들어 Nginx라면:

sudo systemctl status nginx

다음으로 외부 네트워크 연결을 확인합니다.

ping -c 4 8.8.8.8

그리고 도메인 통신을 확인합니다.

curl -I https://example.com

이 과정을 통해 웹서비스 문제인지, 서버 포트 문제인지, 외부 네트워크 문제인지 범위를 좁혀갈 수 있습니다.


마무리

리눅스 서버에서 네트워크 연결 문제를 확인할 때는 하나의 명령어만 사용하는 것보다 여러 명령어를 조합하는 것이 효과적입니다.

ping은 기본적인 네트워크 응답을 확인하고, curl은 실제 HTTP/HTTPS 통신 상태를 확인하며, ss는 서버에서 열려 있는 포트와 네트워크 연결 상태를 확인하는 데 사용합니다.

핵심 명령어를 다시 정리하면 다음과 같습니다.

# 기본 네트워크 연결 확인
ping -c 4 8.8.8.8

# 웹서버 응답 확인
curl -I https://example.com

# 서버의 LISTEN 포트 확인
sudo ss -ltnp

# 특정 포트 확인
sudo ss -ltnp | grep :443

# 서버 내부 웹서비스 확인
curl -I http://127.0.0.1

서버 장애가 발생했을 때는 다음 순서로 기억하면 쉽습니다.

PING
↓
네트워크 통신 확인

CURL
↓
웹서비스 응답 확인

SS
↓
포트와 연결 상태 확인

방화벽 / DNS / 웹서버 설정
↓
문제 원인 확인

특히 ping이 안 된다는 이유만으로 서버 전체 네트워크가 끊겼다고 판단하지 않는 것이 중요합니다. ICMP가 차단된 환경에서는 ping에 응답하지 않아도 웹서비스는 정상적으로 작동할 수 있기 때문입니다.

리눅스 서버 관리에서 네트워크 문제를 빠르게 해결하려면 명령어 자체를 외우는 것보다 각 명령어가 무엇을 확인하는지 이해하고 단계적으로 사용하는 습관을 만드는 것이 중요합니다.


 

 

 


소개 및 문의 · 개인정보처리방침 · 면책조항

© 2026 블로그 이름