네트워크 장애 진단에 사용하는 기본 명령어: ping부터 curl까지

네트워크 장애 진단에 사용하는 기본 명령어: ping부터 curl까지#

디스크립션: 네트워크 장애가 발생했을 때 사용하는 ping, ipconfig·ip, arp·ip neigh, route, tracert·traceroute, netstat·ss, nc, curl 명령의 역할과 올바른 사용 순서를 알아봅니다. IP 설정부터 Gateway·Routing·TCP Port·Application까지 단계적으로 확인하며 각 명령의 결과가 무엇을 의미하고 어디까지 장애 범위를 좁힐 수 있는지 실무 중심으로 정리합니다.

1장 네트워크 장애에서는 명령어보다 순서가 중요하다#

1.1 현장에서 어떤 명령부터 실행해야 할까#

현장 단말이 중앙 Server와 통신되지 않는다고 가정해보겠습니다.

처음 Network를 배울 때는 다음 명령을 하나씩 외우기 쉽습니다.

ping

ipconfig

tracert

arp

netstat

curl

하지만 실제 장애 현장에서 중요한 것은 명령어 개수가 아닙니다.

무엇을 확인하기 위해 어떤 명령을 사용하는가가 중요합니다.

예를 들어 Server 연결이 안 된다고 무조건:

ping 192.168.10.100

부터 실행하고 Ping이 성공하면:

Network 정상

이라고 판단해서는 안 됩니다.

실제 통신은 다음 여러 단계를 거칠 수 있습니다.

Network Interface
↓
IP Address
↓
Subnet
↓
ARP / NDP
↓
Default Gateway
↓
Routing
↓
TCP / UDP
↓
Port
↓
TLS
↓
Application

따라서 장애 분석도 이 순서에 맞춰 범위를 좁혀가는 것이 좋습니다.

1.2 기본 진단 흐름#

네트워크 장애를 처음 확인할 때는 다음 흐름을 사용할 수 있습니다.

1. Interface가 정상인가?
↓
2. IP 설정이 맞는가?
↓
3. 같은 Network의 장비와 통신되는가?
↓
4. Gateway까지 통신되는가?
↓
5. 목적지까지 IP 경로가 존재하는가?
↓
6. 실제 TCP/UDP Port가 동작하는가?
↓
7. Application이 정상 응답하는가?

각 단계마다 사용하는 도구가 다릅니다.

확인 단계	대표 도구
Interface·IP	`ipconfig`, `ip`
기본 연결성	`ping`
같은 Network의 이웃	`arp`, `ip neigh`
Routing	`route`, `ip route`
경로 확인	`tracert`, `traceroute`
Socket·Port	`ss`, `netstat`, `nc`
HTTP·API	`curl`

2장 첫 번째 확인 — Network Interface와 IP 설정#

2.1 가장 먼저 자신의 Network 상태를 확인한다#

Server부터 Ping하기 전에 현재 PC나 장비가 어떤 Network 설정을 가지고 있는지 확인해야 합니다.

Windows에서는:

ipconfig /all

을 사용할 수 있습니다.

Linux에서는:

ip addr

또는 특정 Interface를 지정해:

ip addr show dev eth0

처럼 확인할 수 있습니다.

2.2 무엇을 확인해야 할까#

단순히 IP Address만 보면 안 됩니다.

다음 항목을 같이 봅니다.

Interface 상태

IPv4 / IPv6 Address

Subnet Mask / Prefix

Default Gateway

DNS Server

DHCP 사용 여부

예:

IPv4 Address
192.168.10.45

Subnet Mask
255.255.255.0

Default Gateway
192.168.10.1

DNS
192.168.10.2

라면 이 장비가 192.168.10.0/24 Network에 속해 있다고 볼 수 있습니다.

3장 IP 주소부터 잘못되어 있을 수 있다#

3.1 같은 Network를 사용해야 하는 장비인데 주소가 다르다면#

Server:

192.168.10.100/24

Client:

192.168.20.50/24

이라면 같은 Layer 2 Network에서 직접 통신하는 구조가 아닙니다.

두 Network를 연결하는 Router나 L3 Switch가 필요합니다.

3.2 Subnet Mask도 중요하다#

다음 두 장비가 있습니다.

Device A
192.168.10.20/24

Device B
192.168.10.100/24

둘은 같은 192.168.10.0/24 Network입니다.

하지만 한 장비가 잘못해서:

192.168.10.20/28

처럼 설정돼 있다면 같은 192.168.10.x처럼 보여도 상대 주소를 다른 Network라고 판단할 수 있습니다.

따라서:

IP만 맞으면 된다.

가 아니라:

IP
+
Subnet Mask

를 함께 확인해야 합니다.

4장 169.254.x.x 주소가 보이면 무엇을 의미할까#

Windows 환경 등에서는 DHCP로 정상 주소를 받지 못했을 때 169.254.0.0/16 범위의 IPv4 Link-Local 주소가 자동으로 설정되는 경우가 있습니다.

예:

169.254.32.18

이 주소가 보인다면 먼저:

DHCP 응답을 받지 못했는가?

원래 DHCP를 사용하도록 설계된 장비인가?

정적 IP가 필요한 환경인가?

를 확인합니다.

가능한 원인은:

DHCP Server 장애

잘못된 VLAN

Network 연결 문제

DHCP Relay 문제

잘못된 Client 설정

등 다양합니다.

따라서:

169.254 주소
=
Cable 불량

으로 단정해서는 안 됩니다.

5장 두 번째 확인 — Ping#

5.1 가장 가까운 대상부터 확인한다#

처음부터 원격 Server를 Ping하기보다 Network 구조를 따라 확인하는 편이 좋습니다.

예:

내 IP
192.168.10.45

Gateway
192.168.10.1

Server
10.20.30.100

이라면:

Local Interface
↓
같은 Network 장비
↓
Gateway
↓
Server

순으로 확인할 수 있습니다.

5.2 Gateway Ping#

ping 192.168.10.1

Gateway에 응답이 없다면 원격 Server를 보기 전에 Local Network를 확인해야 할 가능성이 큽니다.

예:

IP 설정

Subnet Mask

VLAN

ARP

Switch Port

Gateway Interface

등입니다.

5.3 목적지 Ping#

ping 10.20.30.100

응답이 돌아오면 적어도 해당 시점에 ICMP Echo Request와 Reply가 왕복할 수 있었다는 중요한 증거가 됩니다.

하지만:

Ping 성공
=
Application 정상

은 아닙니다.

6장 Ping 결과를 어떻게 읽어야 할까#

6.1 정상 응답#

예:

Reply from 192.168.10.100:
bytes=32 time=2ms TTL=63

확인할 수 있는 것은:

대상 IP까지 ICMP Request가 도달하고
ICMP Reply가 돌아왔음

입니다.

6.2 Request Timed Out#

응답이 오지 않았습니다.

가능한 원인은:

대상 장비 Down

Routing 문제

ICMP 차단

Firewall

Packet Loss

Return Path 문제

등입니다.

따라서 Timeout만 보고:

장비가 죽었다.

라고 단정하면 안 됩니다.

6.3 Destination Unreachable#

중간 Router나 Local System에서 목적지에 도달할 수 없다는 오류가 반환될 수도 있습니다.

어디에서 Unreachable이 발생했는지를 같이 확인하면 Routing 문제를 좁히는 데 도움이 됩니다.

7장 Ping은 속도 측정 도구가 아니다#

Ping 결과에서는 RTT를 확인할 수 있습니다.

예:

time=3ms

하지만 이 값 하나만으로:

Network 속도

를 평가해서는 안 됩니다.

Ping은 작은 ICMP Packet의 왕복시간을 측정하는 도구입니다.

실제 Application 성능은:

Bandwidth

Packet Loss

Jitter

Server 처리시간

TCP 상태

Application 처리

등의 영향을 받습니다.

8장 세 번째 확인 — ARP와 Neighbor Table#

8.1 같은 IPv4 Network에서는 MAC Address가 필요하다#

같은 Subnet의 장비와 통신하려면 상대 IP에 대응하는 MAC Address를 알아야 합니다.

IPv4에서는 ARP가 이 역할을 합니다.

Windows:

arp -a

Linux에서는:

ip neigh

를 주로 사용할 수 있습니다.

8.2 Neighbor Table 예#

192.168.10.1
lladdr 00:11:22:33:44:55
REACHABLE

이는 해당 IP와 MAC의 Neighbor Mapping이 존재한다는 의미입니다.

8.3 ARP Entry가 없다고 바로 장애는 아니다#

여기서 주의해야 합니다.

ARP Table은 Cache입니다.

아직 해당 장비와 통신을 시도하지 않았다면 Entry가 없을 수도 있습니다.

또한 목적지가 다른 Subnet이면 목적지 Server의 MAC이 아니라 Default Gateway의 MAC을 찾게 됩니다.

따라서:

Server ARP Entry 없음
=
L2 장애

라고 판단하면 안 됩니다.

9장 ARP가 특히 유용한 상황 — IP 충돌#

예를 들어:

192.168.10.50

이라는 IP를 사용 중인데 Neighbor Mapping이 계속 바뀐다고 생각해보겠습니다.

10:00
192.168.10.50
→ MAC-A

10:01
192.168.10.50
→ MAC-B

IP Conflict 가능성을 확인해야 합니다.

현장에서:

Ping은 되는데
Service가 됐다 안 됐다.

같은 이상한 증상으로 나타날 수도 있습니다.

10장 네 번째 확인 — Routing Table#

10.1 목적지가 다른 Network라면 Route가 필요하다#

Linux:

ip route

Windows:

route print

등으로 Routing Table을 확인할 수 있습니다.

10.2 Linux 예#

default via 192.168.10.1 dev eth0

192.168.10.0/24 dev eth0

의미는:

192.168.10.0/24
→ 직접 eth0으로

그 밖의 목적지
→ 192.168.10.1 Gateway로

입니다.

10.3 Default Gateway가 잘못되면#

같은 Subnet의 장비와는 통신됩니다.

192.168.10.45
↔
192.168.10.100

하지만 다른 Network:

10.20.30.100

으로는 통신되지 않을 수 있습니다.

이 증상은 Default Gateway 문제의 중요한 단서가 됩니다.

11장 같은 Subnet과 다른 Subnet을 먼저 구분하자#

문제 발생 시 다음 질문을 해보는 것이 좋습니다.

내 IP는?

목적지 IP는?

Subnet Mask는?

두 IP의 Network Address는 같은가?

같은 Network라면:

ARP
↓
Ethernet
↓
직접 전달

입니다.

다른 Network라면:

Gateway ARP
↓
Router
↓
Routing
↓
목적지 Network

과정을 거칩니다.

장애 진단 방법이 달라집니다.

12장 다섯 번째 확인 — tracert와 traceroute#

12.1 목적지까지 가는 Layer 3 경로를 본다#

Windows:

tracert 203.0.113.10

Linux:

traceroute 203.0.113.10

를 사용할 수 있습니다.

이 도구는 IP Packet의 TTL 또는 Hop Limit 동작을 이용해 경로상의 Router들을 확인하는 데 도움을 줍니다.

12.2 예#

1   192.168.10.1
2   10.1.0.1
3   10.10.0.5
4   203.0.113.10

단순화하면:

Client
↓
Gateway
↓
Router
↓
Router
↓
Server

경로를 볼 수 있습니다.

13장 traceroute에서 Switch는 일반적으로 보이지 않는다#

중요한 부분입니다.

일반적인 Layer 2 Switch는 IP Packet의 TTL을 감소시키는 Router 역할을 하지 않습니다.

따라서:

traceroute가 특정 Switch에서 멈췄다.

라고 표현하는 것은 일반적으로 정확하지 않습니다.

Traceroute에서 주로 확인하는 것은 Layer 3 Hop, 즉 Router나 Routing 기능을 수행하는 장비입니다.

Switch 장애는:

Switch Port 상태

MAC Table

VLAN

STP

Error Counter

등 별도의 정보로 확인합니다.

14장 traceroute의 별표를 장애로 단정하지 않는다#

다음처럼 보일 수 있습니다.

1   192.168.10.1
2   *
3   *
4   203.0.113.10

중간 장비가 TTL 초과 응답을 보내지 않거나 Firewall에서 제한하기 때문일 수도 있습니다.

최종 목적지까지 정상적으로 도달한다면 중간의 *가 반드시 장애라는 의미는 아닙니다.

따라서 traceroute는 경로 분석의 단서로 사용합니다.

15장 여섯 번째 확인 — 실제 TCP Port#

Ping과 Route가 정상이라면 실제 Service Port를 확인합니다.

예를 들어 Server가:

192.168.10.100:8000

을 사용한다고 가정합니다.

시험 또는 허가된 환경에서:

nc -vz 192.168.10.100 8000

처럼 TCP 연결을 시험할 수 있습니다.

15.1 Ping과 Port Test의 차이#

ping
→ ICMP 확인

nc
→ 실제 TCP Port 연결 확인

입니다.

따라서:

Ping O
nc X

가 충분히 가능합니다.

16장 TCP Port Test의 결과를 구분한다#

16.1 연결 성공#

예:

Connection to 192.168.10.100 8000 succeeded

TCP 3-Way Handshake가 성공했다는 중요한 증거입니다.

하지만 Application이 정상이라는 의미는 아닙니다.

16.2 Connection Refused#

흔히:

Connection refused

가 나타날 수 있습니다.

대표적으로:

Server까지 도달했지만 해당 Port에 LISTEN Service가 없음

또는 중간 장비가 명시적으로 Reject

같은 상황을 확인합니다.

16.3 Timeout#

오랫동안 응답이 없다면:

Firewall Drop

Routing

Return Path

Server 미응답

등을 확인해야 합니다.

17장 UDP Port는 TCP처럼 확인하면 안 된다#

장비가:

UDP 4000

을 사용한다고 가정합니다.

TCP Port Scan과 같은 방식으로 UDP Service 상태를 동일하게 판단하기는 어렵습니다.

UDP에는 TCP의:

SYN
SYN/ACK
ACK

이 없기 때문입니다.

UDP 통신은:

Datagram 송신

Receiver Capture

Application Log

Application ACK

등을 함께 확인해야 할 수 있습니다.

18장 일곱 번째 확인 — ss와 netstat#

18.1 Local Socket 상태를 확인한다#

Linux에서는 ss가 널리 사용됩니다.

예:

ss -tuln

옵션을 단순화하면:

-t
TCP

-u
UDP

-l
Listening

-n
주소와 Port를 숫자로 표시

입니다.

18.2 TCP Listen만 확인#

ss -lnt

특정 Port:

ss -lnt | grep ':8000'

예:

LISTEN
0.0.0.0:8000

이면 해당 Local Address 조건에서 TCP 8000 Service가 Connection을 기다리고 있다는 단서가 됩니다.

19장 Process가 살아 있다고 Port가 열려 있다는 뜻은 아니다#

Application Process가 실행 중이라고 가정합니다.

하지만:

TCP 8000
LISTEN 없음

일 수 있습니다.

가능한 원인은:

Application 초기화 실패

잘못된 Port 설정

Bind 실패

다른 Process가 Port 사용

잘못된 Interface Bind

등입니다.

따라서:

Process 실행 여부

와:

Socket Listening 여부

를 따로 확인합니다.

20장 Bind Address도 확인한다#

예:

127.0.0.1:8000

만 Listen하고 있다면 Server Local에서는 접속할 수 있지만 외부 장비에서는 접근하지 못합니다.

반면:

0.0.0.0:8000

이면 모든 적절한 IPv4 Local Interface에서 Connection을 받을 수 있도록 Bind된 구성일 수 있습니다.

따라서 ss 결과의 Local Address까지 봐야 합니다.

21장 netstat는 언제 사용할까#

Windows에서는:

netstat -ano

등으로 Socket과 Connection을 확인할 수 있습니다.

Linux에서도 netstat를 사용할 수 있는 환경이 있지만 최신 Linux 환경에서는 ss를 사용하는 경우가 많습니다.

중요한 것은 도구 이름보다 다음 정보를 확인하는 것입니다.

LISTEN 중인가?

어떤 Local Address인가?

어떤 Port인가?

Connection 상태는 무엇인가?

22장 여덟 번째 확인 — curl#

22.1 Port 연결보다 한 단계 위를 확인한다#

Server가 HTTP API를 제공한다고 가정합니다.

curl http://192.168.10.200:8080/health

을 사용하면 단순 TCP Port뿐 아니라 실제 HTTP 응답까지 확인할 수 있습니다.

22.2 출력까지 자세히 보고 싶다면#

curl -v http://192.168.10.200:8080/health

처럼 사용할 수 있습니다.

이를 통해 상황에 따라:

TCP Connection

HTTP Request

HTTP Response Header

Status Code

등을 확인할 수 있습니다.

23장 curl 결과는 장애 영역을 크게 좁혀준다#

예를 들어:

HTTP/1.1 200 OK

가 돌아왔다면 Network뿐 아니라 HTTP Application이 해당 요청을 처리했다는 강력한 증거가 됩니다.

반대로:

HTTP/1.1 401 Unauthorized

라면:

Network X

보다는:

인증

문제를 먼저 확인할 수 있습니다.

23.1 대표적인 HTTP 결과#

200
정상 처리

401
인증 필요 또는 인증 실패

403
권한 또는 정책 문제

404
요청한 Resource 없음

500
Server Application 내부 오류

503
Service를 현재 처리하기 어려움

HTTP 응답 자체가 있다는 것은 요청이 적어도 Application 계층 상당 부분까지 도달했다는 중요한 단서입니다.

24장 HTTPS에서는 TLS까지 확인한다#

HTTPS Service는:

TCP
↓
TLS
↓
HTTP

순서입니다.

따라서:

Ping O

TCP 443 O

HTTPS X

상황이 가능합니다.

확인 대상:

Certificate

Hostname

CA

TLS Version

SNI

등입니다.

시험 목적으로 TLS 문제를 확인할 수 있지만 운영 환경에서는 인증서 검증을 무시하는 설정을 정상 설정처럼 사용해서는 안 됩니다.

25장 telnet은 어디에 사용할까#

telnet Client를 TCP Port 연결 확인 용도로 사용하는 경우가 있습니다.

예:

telnet 192.168.10.100 8000

하지만 Telnet Protocol 자체는 평문 통신을 사용하므로 실제 Remote Administration 용도로 사용하는 것은 보안상 적절하지 않은 경우가 많습니다.

단순 TCP 연결 시험이라면 nc 같은 도구가 더 편리할 수 있습니다.

26장 nc는 Network의 범용 시험 도구다#

Netcat은 TCP나 UDP 통신 시험에 사용할 수 있습니다.

예:

nc -vz 192.168.10.100 8000

TCP Port 연결 시험.

시험망에서 Listener를 만들려면 구현에 따라:

nc -l 9000

등을 사용할 수 있습니다.

단 nc는 구현체별로 Option이 다를 수 있습니다.

따라서 실제 환경에서는:

nc -h

또는 해당 배포판 문서를 확인하는 것이 좋습니다.

27장 명령 결과 하나만으로 결론 내리지 않는다#

예를 들어:

Ping 실패

가 나왔다고 하겠습니다.

이것은:

ICMP Reply를 받지 못했다.

는 의미입니다.

바로:

Server Down

이라고 할 수 없습니다.

반대로:

Ping 성공

도:

Service 정상

을 의미하지 않습니다.

각 도구는 특정 경계를 확인하는 증거입니다.

28장 장애 진단은 증거를 연결하는 과정이다#

예:

ipconfig
IP 정상

ping Gateway
정상

ping Server
정상

nc Server 8000
Timeout

이라면 문제 범위가:

기본 IP 연결
O

TCP 8000
X

로 줄어듭니다.

다음에는:

Firewall

Server Port

TCP Packet Capture

를 확인합니다.

29장 사례 1 — IP 설정 자체가 잘못됐다#

현장 PC:

IP
192.168.20.45

Mask
255.255.255.0

Gateway
192.168.10.1

이라면 Gateway가 Client와 동일한 Local Subnet에 있지 않는 비정상적인 구성일 수 있습니다.

우선 Network 설계표와 비교해 주소 구성을 확인해야 합니다.

30장 사례 2 — Gateway가 잘못됐다#

Client:

192.168.10.45/24

같은 Network의 Server:

192.168.10.100

은 통신됩니다.

하지만 중앙 Server:

10.20.30.100

에는 연결되지 않습니다.

Route 확인:

default via 192.168.10.254

실제 Gateway:

192.168.10.1

이었다면 Default Route 문제로 범위를 좁힐 수 있습니다.

31장 사례 3 — Ping은 되지만 TCP Port가 안 된다#

검사:

ping Server
O

nc Server 8000
Timeout

Packet Capture:

SYN
SYN Retransmission
SYN Retransmission

Server에서는 SYN을 볼 수 없습니다.

가능한 확인 영역:

Firewall

ACL

Route

NAT

중간 Network

입니다.

32장 사례 4 — Connection Refused#

검사:

ping Server
O

nc Server 8000
Connection Refused

Server:

ss -lnt

확인 결과:

TCP 8000
LISTEN 없음

이라면 Server Application 또는 Port 설정을 확인해야 합니다.

33장 사례 5 — Port는 정상인데 API가 실패한다#

ping
O

TCP 443
O

curl
HTTP 401

이라면 기본 Network Connection보다:

Token

ID

Password

Device Registration

등 Authentication 영역을 확인할 수 있습니다.

34장 사례 6 — API까지 오지만 Server 내부에서 실패한다#

ping
O

TCP
O

TLS
O

HTTP
500

Server Log:

Database Connection Timeout

이라면 문제 영역은:

Network

보다:

Application
↓
Database

로 좁혀집니다.

35장 traceroute가 정상이어도 Application은 실패할 수 있다#

Traceroute는 Layer 3 Path를 이해하는 데 유용합니다.

하지만:

Traceroute 성공

이:

TCP 8000 허용

을 의미하지는 않습니다.

경로를 따라갈 수 있어도 Firewall에서 특정 TCP Port만 Drop할 수 있기 때문입니다.

36장 ARP가 정상이어도 Server 통신은 실패할 수 있다#

ARP는 Local Network의 Neighbor Resolution을 확인하는 데 유용합니다.

예:

Gateway MAC
정상

이어도 그 이후:

Routing

Firewall

Server

Application

에서 장애가 발생할 수 있습니다.

따라서 ARP 정상 역시 전체 Network 정상과 같은 의미가 아닙니다.

37장 명령어를 계층과 연결해서 이해하자#

Interface / IP
│
├─ ipconfig
└─ ip addr

Layer 2 Neighbor
│
├─ arp
└─ ip neigh

Layer 3
│
├─ ping
├─ route
├─ ip route
├─ tracert
└─ traceroute

Transport
│
├─ nc
├─ ss
└─ netstat

Application
│
└─ curl

이 구조를 기억하면 명령어를 단순 암기하지 않아도 됩니다.

38장 장애 진단에서 가장 효과적인 기본 순서#

38.1 Interface#

Link는 올라와 있는가?

38.2 주소#

IP는 맞는가?

Mask는 맞는가?

Gateway는 맞는가?

38.3 Local Network#

같은 Network 장비와 통신되는가?

38.4 Gateway#

Gateway까지 통신되는가?

38.5 Route#

목적지로 가는 Route가 있는가?

38.6 Service#

TCP/UDP와 Port가 맞는가?

38.7 Application#

실제 Protocol이 정상 응답하는가?

이 순서가 중요합니다.

39장 Windows에서의 기본 진단 흐름#

예:

ipconfig /all

↓

arp -a

↓

ping 192.168.10.1

↓

ping 10.20.30.100

↓

route print

↓

tracert 10.20.30.100

↓

실제 TCP/UDP Port 검사

↓

Application 확인

입니다.

40장 Linux에서의 기본 진단 흐름#

Interface#

ip addr

Neighbor#

ip neigh

Route#

ip route

Ping#

ping -c 4 192.168.10.1

Path#

traceroute 10.20.30.100

TCP Port#

nc -vz 10.20.30.100 8000

Local Socket#

ss -tuln

HTTP#

curl -v http://10.20.30.100:8080/health

이런 순서로 볼 수 있습니다.

41장 현장에서 명령 결과를 기록하는 방법#

단순히:

Ping 됩니다.

라고 기록하는 것보다 다음처럼 남기는 것이 좋습니다.

시간
10:31:20

Client
192.168.10.45

Server
10.20.30.100

Gateway Ping
정상 / 1ms

Server Ping
정상 / 5ms

TCP 8000
Timeout

Traceroute
10.20.30.1까지 확인

Application
Connection Timeout

이렇게 기록하면 다른 담당자와 협업하기 쉽습니다.

42장 정상 장비와 비교하면 더 빨리 찾을 수 있다#

장애 장비:

DEVICE-01

정상 장비:

DEVICE-02

가 같은 Network에 있다면 두 장비를 비교합니다.

항목	정상 장비	장애 장비
IP	정상	정상
Mask	/24	/24
Gateway	192.168.10.1	192.168.10.254
DNS	동일	동일
VLAN	20	20
Server Ping	O	X

이런 비교만으로도 Gateway 설정 문제를 빠르게 찾을 수 있습니다.

43장 재부팅과 설정 변경은 마지막에 고려한다#

장애가 발생하면:

장비 재부팅

Switch 재부팅

Server 재시작

부터 하고 싶어질 수 있습니다.

하지만 먼저:

IP 상태

Route

Socket

Log

Error 상태

를 확보하는 것이 좋습니다.

재부팅하면 장애 당시 증거가 사라질 수 있기 때문입니다.

44장 현장에서 피해야 할 테스트#

임의의 IP 변경#

운영 중인 Network에서 IP Conflict를 만들 수 있습니다.

임의의 Gateway 변경#

원격 관리가 끊길 수 있습니다.

임의의 Firewall 해제#

보안 노출이 발생할 수 있습니다.

운영 장비에 임의 명령 전송#

물리 장비 오동작으로 이어질 수 있습니다.

따라서 진단은 가능한 한 읽기 전용 확인부터 시작하는 것이 좋습니다.

45장 네트워크 진단에서 보안도 고려한다#

명령 자체보다 수집한 결과에 민감한 정보가 있을 수 있습니다.

예:

내부 IP

Hostname

Network 구조

Server Port

Token

URL

관리 Interface

따라서 장애 자료를 외부에 공유할 때 불필요한 정보는 Masking하거나 제거해야 합니다.

46장 각 도구가 알려주는 것과 알려주지 않는 것#

도구	알 수 있는 것	이것만으로 알 수 없는 것
`ipconfig` / `ip`	Local IP 설정	Remote Service 정상 여부
`ping`	ICMP 왕복 여부	TCP·UDP Service 정상
`arp` / `ip neigh`	Local Neighbor 정보	Remote Routing 전체
`route` / `ip route`	Local Routing 결정	중간 장비 실제 전달 여부
`tracert` / `traceroute`	일부 Layer 3 Path	모든 Switch·Firewall 상태
`nc`	TCP 연결 가능 여부 등	Application 업무 정상
`ss` / `netstat`	Local Socket 상태	Remote Application 업무 결과
`curl`	HTTP·HTTPS 계층의 실제 응답	모든 Backend 내부 상태

이 표를 기억하는 것이 중요합니다.

모든 것을 보여주는 명령어는 없습니다.

47장 증상별로 어떤 도구를 먼저 사용할까#

증상	우선 확인
IP가 없어 보임	`ipconfig`, `ip addr`
같은 Network 장비 통신 불가	`ping`, `ip neigh`, `arp`
외부 Network만 실패	`ip route`, `route print`
어느 Layer 3 구간인지 확인	`tracert`, `traceroute`
Ping은 되지만 Service 안 됨	`nc`
Server Port 상태 확인	`ss`, `netstat`
Web/API가 실제 동작하는지 확인	`curl`
TCP 장애가 더 복잡함	Packet Capture
간헐 장애	Log·Metric·Packet Capture

48장 네트워크 장애의 기본 진단 흐름#

전체를 하나로 연결하면 다음과 같습니다.

Power / Link
↓
Interface
↓
IP Address
↓
Subnet Mask
↓
ARP / NDP
↓
Default Gateway
↓
Routing Table
↓
Layer 3 Path
↓
TCP / UDP
↓
Port
↓
TLS
↓
Application
↓
Backend

그리고 도구를 연결하면:

Power / Link
↓
ipconfig / ip
↓
arp / ip neigh
↓
ping
↓
route / ip route
↓
tracert / traceroute
↓
nc
↓
ss / netstat
↓
curl
↓
Packet Capture / Log

입니다.

49장 자주 발생하는 오해#

49.1 Ping이 되면 Network는 전부 정상이다?#

아닙니다.

ICMP 왕복이 정상이라는 중요한 증거일 뿐입니다.

49.2 Ping이 안 되면 장비가 꺼져 있다?#

반드시 그렇지 않습니다.

ICMP가 차단됐을 수도 있습니다.

49.3 traceroute에서 `*`가 나오면 그 Router가 고장났다?#

반드시 그렇지 않습니다.

TTL 관련 응답을 보내지 않거나 Firewall에서 차단할 수도 있습니다.

49.4 traceroute로 어느 Switch가 문제인지 알 수 있다?#

일반적인 Layer 2 Switch는 traceroute Hop으로 나타나지 않습니다.

Switch는 별도 Port·VLAN·MAC·Error 정보를 확인해야 합니다.

49.5 ARP Table에 대상이 없으면 Cable 장애다?#

아닙니다.

아직 통신하지 않았거나, Cache가 만료됐거나, 목적지가 다른 Subnet일 수도 있습니다.

49.6 Port 연결이 되면 Application은 정상이다?#

아닙니다.

TCP 이후에도:

TLS

Authentication

Application

Database

에서 실패할 수 있습니다.

50장 자기 점검#

50.1 통신 장애가 발생하면 가장 먼저 어떤 명령을 사용하는 것이 좋은가#

무조건 ping부터 시작하기보다 자신의 Interface와 IP 설정을 먼저 확인하는 것이 좋습니다.

Windows에서는:

ipconfig /all

Linux에서는:

ip addr

등을 사용할 수 있습니다.

50.2 Ping은 되는데 Application 연결이 되지 않는다면 무엇을 확인할까#

실제 Protocol과 Destination Port를 확인하고 TCP라면 Port 연결과 Handshake를 확인합니다.

이후 Firewall, Service 상태, TLS, Application 순으로 범위를 좁힙니다.

50.3 Default Gateway가 잘못되면 어떤 증상이 나타날 수 있는가#

같은 Local Subnet의 장비와는 통신되지만 다른 Network의 Server와 통신되지 않을 수 있습니다.

50.4 traceroute에서 중간 Hop이 `*`이면 장애인가#

반드시 아닙니다.

해당 장비가 TTL 초과 응답을 제한하고 있을 수 있습니다.

최종 목적지와 실제 Service 상태를 함께 확인해야 합니다.

50.5 `ss`에서 Port가 LISTEN하지 않는다면 무엇을 확인해야 할까#

Application Process, Port 설정, Bind Address, Application Log 등을 확인합니다.

51장 이 글을 마치며#

네트워크 장애 진단에서 중요한 것은 명령어를 많이 알고 있는 것이 아닙니다.

다음과 같이 질문을 순서대로 던질 수 있어야 합니다.

내 Network Interface는 정상인가?
↓
IP 설정은 맞는가?
↓
같은 Network와 통신되는가?
↓
Gateway는 통신되는가?
↓
목적지 Route가 있는가?
↓
실제 Service Port가 열려 있는가?
↓
Application이 응답하는가?

각 질문에는 알맞은 도구가 있습니다.

IP 설정
→ ipconfig / ip

기본 연결성
→ ping

Neighbor
→ arp / ip neigh

Routing
→ route / ip route

Layer 3 경로
→ tracert / traceroute

TCP Port
→ nc

Socket
→ ss / netstat

HTTP / API
→ curl

그리고 가장 중요한 것은 각 도구가 어디까지 확인해주는지를 정확하게 아는 것입니다.

ping 성공
≠
TCP 정상

TCP 연결 성공
≠
Application 정상

HTTP 응답
≠
업무 처리 정상

네트워크 장애를 만났을 때 한 번에 원인을 맞히려고 하지 말고:

확인
↓
정상 구간 분리
↓
최초 실패 지점 확인
↓
다음 도구 선택

과정을 반복해야 합니다.

특히 다음 네 가지를 기억하면 됩니다.

ipconfig와 ip는 내가 Network에서 어떤 주소와 경로를 사용하고 있는지 확인하는 출발점입니다.

ping과 traceroute는 Network 상태를 판단하는 증거이지 서비스 전체의 정상 여부를 증명하는 도구가 아닙니다.

nc, ss, curl로 올라갈수록 실제 Service와 Application에 더 가까운 상태를 확인할 수 있습니다.

좋은 장애 진단은 명령어를 무작정 실행하는 것이 아니라, 직전 결과에 따라 다음 명령을 선택하는 과정입니다.

결국 현장에서 필요한 것은 명령어 암기가 아니라:

지금 어느 계층까지 정상인가?

를 계속 확인하면서 장애가 처음 발생하는 경계를 찾아가는 사고방식입니다.