리눅스 서버에서 접속이 안 될 때 바로 방화벽부터 의심하기보다 curl 명령어로 실제 통신 여부를 먼저 확인하는 것이 좋습니다.
이 글에서는 curl로 HTTP 응답 코드, 타임아웃, 연결 단계까지 확인하는 기본 방법을 정리합니다.
브라우저에서는 접속이 안 되고, 애플리케이션에서는 타임아웃이 나고, 담당자는 “방화벽 문제 아닌가요?”라고 물어볼 때가 있습니다.
이럴 때 바로 방화벽부터 의심하기보다, 먼저 서버에서 실제 통신이 되는지 확인해 보는 게 좋습니다.
그때 자주 쓰는 명령어가 curl입니다.
curl은 서버에서 특정 URL이나 API로 요청을 보내고, 응답이 오는지 확인할 때 많이 사용합니다.
웹 서비스, API, 내부 연동 URL, 헬스체크 주소 등을 테스트할 때 기본적으로 많이 쓰는 명령어입니다.
이번 글에서는 초보 운영자 기준으로 curl을 이용해 서버 통신을 확인하는 방법을 정리해 보겠습니다.
curl은 언제 사용할까?
curl은 단순히 웹페이지를 보는 명령어가 아닙니다.
운영 중에는 아래 상황에서 자주 사용합니다.
웹 서비스 접속 여부 확인
API 응답 여부 확인
도메인 연결 확인
포트 통신 확인
HTTP 응답 코드 확인
서버 간 통신 테스트
헬스체크 URL 확인
타임아웃 여부 확인예를 들어 이런 상황입니다.
서비스는 떠 있는데 접속이 안 됨
방화벽을 열었다는데 통신이 안 됨
API 연동이 실패함
도메인은 맞는데 응답이 없음
포트는 열렸는데 애플리케이션 응답이 이상함이럴 때 curl로 직접 요청을 보내 보면, 어디까지 통신이 되는지 감을 잡을 수 있습니다.
기본 사용법
가장 기본 형태는 아래입니다.
curl URL예를 들어 웹 서버에 요청을 보내려면 이렇게 입력합니다.
curl http://example.comHTTPS 주소라면 이렇게 볼 수 있습니다.
curl https://example.com응답이 정상이라면 HTML이나 JSON 같은 내용이 출력됩니다.
하지만 운영 상황에서는 본문 전체보다 응답 코드나 연결 여부를 보는 경우가 많습니다.
응답 코드만 확인하기
서비스가 정상인지 볼 때는 HTTP 상태 코드를 확인하는 경우가 많습니다.
아래 명령어를 사용할 수 있습니다.
curl -o /dev/null -s -w "%{http_code}\n" https://example.com옵션을 간단히 보면 이렇습니다.
-o /dev/null : 응답 본문은 출력하지 않음
-s : 진행 상태를 조용히 출력
-w : 원하는 정보만 출력
%{http_code} : HTTP 응답 코드 출력예를 들어 결과가 이렇게 나오면:
200HTTP 응답은 정상적으로 온 것입니다.
자주 보는 응답 코드는 아래 정도입니다.
200 : 정상 응답
301 / 302 : 리다이렉트
400 : 잘못된 요청
401 / 403 : 인증 또는 권한 문제
404 : 경로 없음
500 : 서버 내부 오류
502 / 503 / 504 : 게이트웨이, 백엔드, 타임아웃 문제 가능성여기서 중요한 점은 curl이 성공했다고 해서 서비스가 완전히 정상이라는 뜻은 아니라는 것입니다.
하지만 최소한 요청이 서버까지 갔고, 어떤 응답이 돌아오는지는 확인할 수 있습니다.
헤더만 확인하기
본문은 필요 없고 응답 헤더만 보고 싶을 때는 -I 옵션을 사용할 수 있습니다.
curl -I https://example.com예시입니다.
HTTP/1.1 200 OK
Content-Type: text/html
Server: nginx이렇게 보면 응답 코드, 서버 정보, 콘텐츠 타입 등을 빠르게 확인할 수 있습니다.
단, 모든 서버가 HEAD 요청을 정상 지원하는 것은 아닙니다.
curl -I에서는 안 되는데 일반 curl 요청은 되는 경우도 있습니다.
그럴 때는 아래처럼 일반 GET 요청으로 응답 코드를 확인하는 편이 더 안전합니다.
curl -o /dev/null -s -w "%{http_code}\n" https://example.com포트까지 지정해서 확인하기
특정 포트로 통신이 되는지 확인하고 싶다면 URL에 포트를 붙이면 됩니다.
curl http://example.com:8080HTTPS 포트라면 이렇게 볼 수 있습니다.
curl https://example.com:8443내부 서버 IP로도 테스트할 수 있습니다.
curl http://10.10.10.10:8080다만 블로그나 외부 문서에는 실제 IP, 실제 도메인을 쓰지 않는 게 좋습니다.
예시는 항상 가짜 값으로 정리하는 것이 안전합니다.
타임아웃 걸어서 확인하기
운영 서버에서 curl을 쓸 때는 타임아웃을 걸어두는 것이 좋습니다.
그냥 실행했다가 응답이 없으면 오래 기다릴 수 있습니다.
curl --connect-timeout 3 https://example.com연결과 전체 요청 시간을 같이 제한하고 싶다면 이렇게 쓸 수 있습니다.
curl --connect-timeout 3 --max-time 5 https://example.com의미는 대략 이렇게 보면 됩니다.
--connect-timeout 3 : 연결 시도 시간 3초 제한
--max-time 5 : 전체 요청 시간 5초 제한운영 중 통신 테스트를 할 때는 이런 식으로 시간을 제한해 두는 게 좋습니다.
응답 시간 확인하기
서버가 아예 안 되는 게 아니라 느린 경우도 있습니다.
이럴 때는 응답 시간을 같이 보면 좋습니다.
curl -o /dev/null -s -w "code:%{http_code} time:%{time_total}\n" https://example.com예시 결과입니다.
code:200 time:0.245이렇게 나오면 HTTP 응답 코드는 200이고, 전체 응답 시간은 약 0.245초입니다.
반대로 이렇게 나오면:
code:200 time:8.532응답은 오지만 시간이 오래 걸린다는 뜻입니다.
이 경우에는 단순 방화벽 문제라기보다 애플리케이션 처리 지연, DB 지연, 외부 연동 지연 등을 같이 봐야 할 수 있습니다.
상세 로그 보기: -v 옵션
통신이 어디서 막히는지 더 자세히 보고 싶다면 -v 옵션을 사용할 수 있습니다.
curl -v https://example.com-v는 verbose 옵션입니다.
DNS 확인, 연결 시도, TLS 협상, 요청/응답 헤더 등을 더 자세히 보여줍니다.
예를 들어 아래 같은 정보를 볼 수 있습니다.
Trying 10.10.10.10...
Connected to example.com
TLS handshake
HTTP/1.1 200 OK여기서 어느 단계까지 진행됐는지 보면 도움이 됩니다.
Trying에서 멈춤 → 네트워크 연결 문제 가능성
Connected까지 됨 → TCP 연결은 성공
TLS에서 실패 → 인증서 또는 HTTPS 설정 문제 가능성
HTTP 응답 코드 확인됨 → 애플리케이션 응답까지 도달다만 -v 출력에는 내부 IP, 인증서 정보, 헤더 정보가 포함될 수 있습니다.
외부 공유할 때는 민감한 정보가 없는지 확인해야 합니다.
인증서 문제 임시 확인: -k 옵션
HTTPS 통신에서 인증서 문제로 실패하는 경우가 있습니다.
예를 들어 사설 인증서나 인증서 체인 문제로 아래처럼 실패할 수 있습니다.
SSL certificate problem테스트 목적으로만 아래처럼 -k 옵션을 붙여 확인할 수 있습니다.
curl -k https://example.com-k는 인증서 검증을 무시하고 요청을 보내는 옵션입니다.
다만 운영 기준에서는 주의해야 합니다.
-k로 통신이 된다고 해서 인증서 문제가 해결된 것은 아닙니다.
단지 “인증서 검증을 무시하면 연결은 되는지” 확인하는 용도입니다.
실제 서비스에서는 인증서 체인, 만료일, 도메인 일치 여부를 제대로 확인해야 합니다.
Host 헤더 지정해서 테스트하기
IP로 접속하되, 도메인 기준으로 서비스가 동작하는지 확인해야 할 때가 있습니다.
예를 들어 웹 서버나 WAS가 Host 헤더를 기준으로 라우팅하는 경우입니다.
이럴 때는 아래처럼 테스트할 수 있습니다.
curl -H "Host: example.com" http://10.10.10.10포트까지 지정하면:
curl -H "Host: example.com" http://10.10.10.10:8080이 방법은 로드밸런서나 웹 서버 뒤쪽 서버를 직접 확인할 때 유용할 수 있습니다.
다만 실제 운영 환경에서는 도메인, 내부 IP, 서비스명이 민감 정보일 수 있으니 외부 공유 시 반드시 가려야 합니다.
curl 결과를 어떻게 판단할까?
curl 결과는 단순히 성공/실패만 보는 게 아닙니다.
대략 아래처럼 볼 수 있습니다.
응답 코드 200
→ 요청은 정상적으로 처리됨
응답 코드 404
→ 서버는 응답했지만 경로가 없을 수 있음
응답 코드 401 / 403
→ 인증이나 권한 문제 가능성
응답 코드 500
→ 애플리케이션 내부 오류 가능성
응답 코드 502 / 503 / 504
→ 게이트웨이, 백엔드, 타임아웃 문제 가능성
Connection refused
→ 대상 포트에 서비스가 떠 있지 않거나 차단 가능성
Connection timed out
→ 네트워크, 방화벽, 라우팅 문제 가능성
Could not resolve host
→ DNS 문제 가능성여기서 중요한 건 하나입니다.
curl 결과는 “어디까지 됐는지”를 나눠 보는 힌트입니다.
바로 원인을 단정하기보다, 다음 확인으로 연결해야 합니다.
curl과 ss를 같이 보면 좋다
curl은 요청을 보내는 쪽에서 확인하는 명령어입니다.
반대로 서버 안에서 포트가 열려 있는지 보려면 ss를 같이 봅니다.
ss -lntp특정 포트만 확인하려면:
ss -lntp | grep ':8080'예를 들어 상황을 나눠 보면 이렇게 볼 수 있습니다.
ss에서 포트가 안 보임
→ 서비스가 안 떠 있을 가능성
ss에서 포트는 보임
curl localhost는 됨
외부 curl은 안 됨
→ 방화벽, 보안그룹, 라우팅 가능성
curl IP는 됨
curl 도메인은 안 됨
→ DNS 또는 Host 설정 문제 가능성
curl은 되는데 응답이 느림
→ 애플리케이션, DB, 외부 연동 지연 가능성이렇게 보면 “무조건 방화벽 문제”처럼 단정하지 않고 단계별로 확인할 수 있습니다.
서버 통신 테스트 기본 순서
초보 운영자 기준으로는 아래 순서가 무난합니다.
1. 대상 URL과 포트 확인
2. curl로 기본 응답 확인
3. HTTP 응답 코드 확인
4. 타임아웃 옵션을 걸고 재확인
5. -v 옵션으로 연결 단계 확인
6. 서버 안에서 ss로 포트 LISTEN 확인
7. DNS, 방화벽, 애플리케이션 로그 순서로 추가 확인명령어로 정리하면 아래와 같습니다.
curl https://example.comcurl -o /dev/null -s -w "%{http_code}\n" https://example.comcurl --connect-timeout 3 --max-time 5 https://example.comcurl -v https://example.comss -lntp | grep ':8080'실무 보고 예시
서버 통신 문제를 확인할 때는 “안 됩니다”보다 어떤 테스트를 했는지 같이 적는 게 좋습니다.
예를 들어 이렇게 정리할 수 있습니다.
대상 URL에 대해 서버 내부에서 curl 테스트를 진행했습니다.
HTTP 응답 코드는 200으로 확인되어 기본 통신은 가능한 상태로 보입니다.
다만 응답 시간이 약 5초 이상으로 확인되어 애플리케이션 처리 지연 또는 백엔드 연동 지연 가능성을 추가 확인하겠습니다.포트가 안 열려 있을 때는 이렇게 쓸 수 있습니다.
대상 서버에서 ss -lntp 확인 결과 8080 포트 LISTEN 상태가 확인되지 않습니다.
curl 요청 시 Connection refused가 발생하여 서비스 프로세스 기동 여부를 우선 확인하겠습니다.타임아웃이 발생할 때는 이렇게 정리할 수 있습니다.
curl 테스트 결과 대상 URL 접속 시 Connection timed out이 발생했습니다.
대상 포트 LISTEN 상태, 방화벽 정책, 라우팅 경로를 순서대로 추가 확인하겠습니다.이렇게 쓰면 문제 위치를 단계적으로 좁혀가는 느낌이 납니다.
정리
리눅스 서버에서 통신 문제가 발생했을 때 바로 방화벽부터 의심하면 안 됩니다.
먼저 curl로 실제 요청이 되는지 확인하는 것이 좋습니다.
기본 명령어는 아래입니다.
curl https://example.com응답 코드만 확인하려면:
curl -o /dev/null -s -w "%{http_code}\n" https://example.com타임아웃을 걸고 확인하려면:
curl --connect-timeout 3 --max-time 5 https://example.com상세 연결 과정을 보려면:
curl -v https://example.com초보 운영자라면 아래 문장을 기억하면 좋습니다.
접속이 안 된다고 바로 방화벽부터 보지 말고, curl로 어디까지 통신되는지 먼저 확인한다.서버 통신 확인도 결국은 확인 → 판단 → 조치 순서가 중요합니다.
서버 통신 문제는 포트, 프로세스, 방화벽, 애플리케이션 응답이 함께 연결되는 경우가 많습니다.
아래 글도 함께 보면 좋습니다.
- 리눅스 서버 접속이 안 될 때 ss -lntp로 포트 확인하는 법
- 리눅스 서버 서비스가 안 떠 있을 때 ps -ef로 프로세스 확인하는 법
- 리눅스 서버가 느려졌을 때 바로 재기동하기 전 기본 점검 순서
- 리눅스 서버가 느릴 때 디스크 I/O 문제를 iostat으로 확인하는 법
접속 장애를 ping, nc, curl, DNS 순서로 정리해서 보고 싶다면 아래 글을 함께 보면 좋습니다.
https://opsnote.tistory.com/71
리눅스 서버 접속 장애 확인 순서 총정리
리눅스 서버를 운영하다 보면 가장 자주 듣는 말 중 하나가 있습니다.접속이 안 됩니다.사이트가 안 열립니다.서버가 죽은 것 같습니다.도메인이 안 됩니다.포트가 막힌 것 같습니다. 처음 들으
opsnote.tistory.com
리눅스 서버 장애 대응 전체 흐름은 아래 글에서 정리했습니다.
https://opsnote.tistory.com/69
초보 운영자를 위한 리눅스 서버 장애 대응 순서 총정리
리눅스 서버를 운영하다 보면 어느 날 갑자기 이런 말을 듣게 됩니다.서버가 느립니다.접속이 안 됩니다.서비스가 안 뜹니다.디스크가 가득 찼습니다.로그가 계속 쌓입니다.재기동하면 될까요?
opsnote.tistory.com
다음 글에서는 netstat과 ss의 차이, 그리고 왜 요즘은 ss 명령어를 더 많이 쓰는지 정리해 보겠습니다.
'리눅스' 카테고리의 다른 글
| 리눅스 서버 재기동 전 바로 껐다 켜지 말고 확인해야 할 체크리스트 (0) | 2026.05.20 |
|---|---|
| 리눅스 서버 접속이 안 될 때 netstat보다 ss로 포트 확인하는 이유 (0) | 2026.05.19 |
| 리눅스 서버가 느릴 때 디스크 I/O 문제를 iostat으로 확인하는 법 (0) | 2026.05.17 |
| 리눅스 서버가 느려졌을 때 바로 재기동하기 전 기본 점검 순서 (0) | 2026.05.16 |
| 리눅스 서버 메모리 부족(OOM) 발생했을 때 로그 확인하는 법 (0) | 2026.05.16 |