HTTP와 HTTPS 동작 원리 및 Linux 실전 장애 분석

admin · 2026-10-19 · 조회 4

HTTP와 HTTPS 동작 원리 및 Linux 실전 장애 분석

1. HTTP와 HTTPS란 무엇인가?

시스템 엔지니어가 웹 서버를 운영하다 보면 다음과 같은 장애를 자주 접한다.

서버 IP로는 통신되지만 웹 페이지가 열리지 않는다.
HTTP 접속은 되지만 HTTPS 접속은 실패한다.
Nginx는 실행 중인데 브라우저에서 502 Bad Gateway가 발생한다.
TCP 443번 포트는 열려 있지만 TLS 인증서 오류가 발생한다.
특정 URL에서만 404 Not Found가 발생한다.
웹 서비스가 간헐적으로 504 Gateway Timeout을 반환한다.

이러한 문제를 분석하려면 HTTP와 HTTPS가 어떻게 동작하는지 이해해야 한다.

**HTTP(Hypertext Transfer Protocol)**는 클라이언트와 웹 서버가 요청과 응답을 주고받기 위한 애플리케이션 계층 프로토콜이다.

**HTTPS(HTTP Secure)**는 HTTP 통신에 TLS를 적용해 통신 내용을 보호하는 방식이다.

일반적인 HTTP 통신은 암호화되지 않기 때문에 네트워크 경로에서 패킷을 관찰할 수 있는 공격자가 통신 내용을 읽거나 변조할 위험이 있다.

HTTPS는 TLS를 이용해 통신 내용을 암호화하고, 서버 인증서를 통해 서버의 신원을 검증할 수 있도록 한다.

두 프로토콜의 차이는 다음과 같다.

구분HTTPHTTPS기본 포트TCP 80TCP 443통신 암호화기본적으로 없음TLS로 보호서버 인증HTTP 자체에는 TLS 인증서 검증이 없음일반적으로 서버 인증서 검증패킷 분석HTTP 요청과 응답 내용을 확인할 수 있음일반적으로 HTTP 내용은 암호화되어 있음주요 용도내부 테스트 등일반적인 웹 서비스장애 분석TCP 및 HTTP 요청·응답 확인TCP, TLS, HTTP 계층을 구분해 확인

단, HTTP가 반드시 80번 포트를 사용하거나 HTTPS가 반드시 443번 포트를 사용해야 하는 것은 아니다. 이는 일반적인 기본 포트이며 실제 서비스에서는 다른 포트를 사용할 수 있다.

2. 브라우저에서 웹 서버까지의 통신 과정

사용자가 브라우저에 다음 주소를 입력했다고 가정하자.

https://www.example.com

브라우저가 웹 페이지를 표시하기까지 여러 단계가 진행된다.

사용자 브라우저
      |
      | 1. DNS 조회
      v
DNS 서버
      |
      | 2. 서버 IP 주소 확인
      v
웹 서버 IP
      |
      | 3. TCP 연결 수립
      v
TCP 443 포트
      |
      | 4. TLS Handshake
      v
HTTPS 연결
      |
      | 5. HTTP 요청 전송
      v
웹 서버 또는 Nginx
      |
      | 6. 요청 처리
      v
백엔드 애플리케이션
      |
      | 7. HTTP 응답 반환
      v
브라우저 화면 표시

각 단계에서 장애가 발생할 수 있다.

예를 들어 DNS 조회가 실패하면 서버 IP를 찾지 못할 수 있다. TCP 연결이 실패하면 서버 포트에 접근할 수 없다. TLS 단계에서 문제가 발생하면 인증서 오류가 나타날 수 있다. HTTP 처리 단계에서 문제가 발생하면 404, 500, 502 등의 응답이 반환될 수 있다.

따라서 웹 서비스 장애를 분석할 때는 브라우저 오류 메시지만 보고 원인을 단정하지 말고, 어느 단계까지 정상적으로 진행되는지 확인해야 한다.

3. HTTP 요청과 응답의 구조

HTTP는 요청(Request)과 응답(Response)을 주고받는 방식으로 동작한다.

클라이언트가 웹 서버에 페이지를 요청하면 서버는 요청을 처리한 후 결과를 응답한다.

3-1. HTTP 요청 구조

다음은 HTTP 요청의 간단한 예시다.

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html
Connection: keep-alive

각 항목의 의미는 다음과 같다.

항목설명GETHTTP 메서드/index.html요청 경로HTTP/1.1HTTP 버전Host요청 대상 호스트User-Agent클라이언트 정보Accept클라이언트가 받을 수 있는 콘텐츠 유형ConnectionHTTP/1.x 연결 관리 관련 헤더

HTTP/1.1에서는 일반적으로 Host 헤더가 필요하다. 하나의 IP 주소에서 여러 도메인의 웹 서비스를 운영할 수 있기 때문이다.

예를 들어 다음 두 도메인이 같은 IP 주소를 사용한다고 가정하자.

www.example.com  -> 192.168.10.100
api.example.com  -> 192.168.10.100

웹 서버는 HTTP 요청의 호스트 정보를 이용해 적절한 가상 호스트 설정을 선택할 수 있다.

HTTPS에서는 TLS 연결을 시작할 때 SNI(Server Name Indication)를 통해 클라이언트가 접속하려는 호스트 이름을 전달할 수도 있다. 서버는 이를 바탕으로 적절한 인증서를 선택할 수 있다.

3-2. HTTP 응답 구조

웹 서버가 요청을 처리하면 다음과 같은 응답을 반환할 수 있다.

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 1256

<!DOCTYPE html>
<html>
<head>
    <title>Example</title>
</head>
<body>
    <h1>Hello World</h1>
</body>
</html>

응답은 크게 세 부분으로 나뉜다.

상태 줄(Status Line)
응답 헤더(Response Headers)
응답 본문(Response Body)

200 OK는 요청이 정상적으로 처리되었음을 나타낸다.

Content-Type은 응답 본문의 미디어 유형을 나타내고, Content-Length는 본문 길이를 바이트 단위로 나타낸다.

실제 응답 헤더와 본문은 서버 설정, 콘텐츠 유형, 압축 여부, HTTP 버전 등에 따라 달라진다.

4. HTTP 메서드 이해하기

HTTP 메서드는 클라이언트가 서버에 어떤 작업을 요청하는지 나타낸다.

메서드주요 목적일반적인 사용 예GET리소스 조회웹 페이지, API 데이터 조회POST데이터 제출 또는 처리 요청로그인, 데이터 생성PUT리소스 전체 교체 성격의 요청설정 리소스 갱신PATCH리소스 일부 수정사용자 정보 일부 변경DELETE리소스 삭제데이터 삭제HEADGET과 유사하지만 응답 본문 없이 헤더 확인응답 헤더 점검OPTIONS지원 메서드 등 확인CORS 사전 요청 등에 활용

GET은 일반적으로 조회에 사용하며, HTTP 의미상 안전한 메서드로 정의된다. 반면 POST는 데이터 제출이나 상태 변경 작업에 사용될 수 있다.

시스템 엔지니어가 HTTP 메서드를 알아야 하는 이유는 웹 서버와 API 장애를 분석할 때 요청 메서드가 문제의 원인이 될 수 있기 때문이다.

예를 들어 브라우저에서는 페이지가 열리지만 API 호출에서 405 Method Not Allowed가 발생할 수 있다.

이는 서버가 해당 경로에서 요청 메서드를 허용하지 않는 경우 나타날 수 있다.

다음과 같이 확인할 수 있다.

curl -i https://www.example.com/api/

특정 메서드를 직접 확인하려면 다음과 같이 실행한다.

curl -i -X OPTIONS https://www.example.com/api/

다만 OPTIONS 응답만으로 서버의 모든 동작을 확정할 수는 없다. 실제 애플리케이션의 라우팅 설정과 인증 정책도 함께 확인해야 한다.

5. HTTP 상태 코드 완벽 이해

HTTP 상태 코드는 서버가 요청을 어떻게 처리했는지 나타낸다.

상태 코드는 첫 번째 숫자를 기준으로 다섯 가지 그룹으로 구분한다.

범위분류의미1xxInformational처리 진행 중인 정보성 응답2xxSuccess요청 성공3xxRedirection추가 이동 또는 리다이렉션4xxClient Error요청 또는 클라이언트 측 조건 관련 문제5xxServer Error서버가 요청을 처리하는 과정에서 발생한 문제

5-1. 자주 만나는 상태 코드

코드의미주요 확인 사항200OK요청 정상 처리201Created리소스 생성 성공204No Content성공했지만 반환할 본문이 없음301Moved Permanently영구 리다이렉션302Found임시 리다이렉션304Not Modified캐시된 리소스 재사용 가능400Bad Request요청 형식이나 데이터 확인401Unauthorized인증 정보 확인403Forbidden접근 권한 및 정책 확인404Not FoundURL, 라우팅, 리소스 경로 확인405Method Not Allowed허용된 HTTP 메서드 확인408Request Timeout요청 수신 시간 초과 관련 확인429Too Many Requests요청 제한 및 Rate Limit 확인500Internal Server Error애플리케이션 오류 로그 확인502Bad Gateway프록시와 백엔드 통신 확인503Service Unavailable서비스 가용성 및 과부하 확인504Gateway Timeout프록시의 업스트림 응답 시간 초과 확인

여기서 중요한 점은 HTTP 상태 코드만으로 장애 원인을 확정할 수 없다는 것이다.

예를 들어 502 Bad Gateway는 Nginx가 백엔드 서버와 통신하는 과정에서 문제가 발생했을 때 나타날 수 있다. 하지만 백엔드 서비스 중단, 잘못된 업스트림 주소, 연결 거부, 프로토콜 불일치 등 다양한 원인이 가능하다.

따라서 상태 코드를 확인한 다음 관련 로그와 실제 네트워크 연결을 점검해야 한다.

6. Linux에서 HTTP 응답 확인하기

웹 서버에 문제가 발생하면 가장 먼저 curl을 이용해 HTTP 응답을 확인할 수 있다.

6-1. 기본 요청

curl -i http://www.example.com

-i 옵션은 응답 헤더와 본문을 함께 출력한다.

응답 헤더만 확인하려면 다음 명령어를 사용한다.

curl -I https://www.example.com

-I는 HEAD 요청을 사용하므로 서버가 HEAD 메서드를 지원하지 않거나 GET과 다른 동작을 보이는 경우 결과가 달라질 수 있다.

6-2. 응답 시간 측정

curl -sS -o /dev/null \
  -w 'HTTP Code: %{http_code}\nDNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTLS: %{time_appconnect}s\nFirst Byte: %{time_starttransfer}s\nTotal: %{time_total}s\n' \
  https://www.example.com

주요 항목은 다음과 같다.

항목의미time_namelookup이름 조회 완료까지 걸린 시간time_connectTCP 연결 완료까지 걸린 시간time_appconnectHTTPS의 TLS 연결 완료까지 걸린 시간time_starttransfer요청 시작부터 첫 바이트를 받을 때까지 걸린 시간time_total전체 요청 완료까지 걸린 시간

이 값을 이용하면 DNS 조회, TCP 연결, TLS 연결, 서버 응답 중 어느 구간에서 지연이 발생하는지 추정할 수 있다.

다만 각 시간은 누적 기준으로 측정되므로 단순히 모든 값을 더해서 전체 시간을 계산하면 안 된다. 또한 HTTP 버전, 연결 재사용, 프록시, 리다이렉션 등의 조건에 따라 해석이 달라질 수 있다.

6-3. 리다이렉션 확인

curl -I http://www.example.com

HTTP 요청이 HTTPS로 리다이렉션되는지 확인할 수 있다.

리다이렉션을 따라가려면 다음과 같이 실행한다.

curl -IL http://www.example.com

-L 옵션은 리다이렉션을 따라간다.

HTTP에서 HTTPS로 전환하는 구성이라면 응답에 다음과 같은 헤더가 나타날 수 있다.

HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/

실제 상태 코드는 서버 설정에 따라 301 또는 308 등으로 다를 수 있다.

7. HTTPS와 TLS의 동작 원리

HTTPS는 HTTP 메시지를 TLS로 보호하여 전송한다.

일반적인 HTTPS 연결에서는 먼저 TCP 연결을 수립하고, 그 위에서 TLS Handshake를 수행한 다음 HTTP 요청과 응답을 주고받는다.

Client                         Web Server
  |                                 |
  |------ TCP Handshake ----------->|
  |                                 |
  |------ TLS Handshake ----------->|
  |<----- TLS Handshake ------------|
  |                                 |
  |====== 암호화된 HTTP 요청 =======>|
  |<===== 암호화된 HTTP 응답 =======|
  |                                 |

TLS Handshake에서는 구성에 따라 다음 작업이 수행된다.

TLS 버전과 암호화 방식 협상
서버 인증서 전달
인증서의 유효성과 호스트 이름 검증
키 교환 및 세션 키 설정
이후 통신을 보호하기 위한 암호화 상태 확립

현대적인 TLS 1.3 연결에서는 일반적으로 서버 인증서와 키 교환이 Handshake 과정에 포함된다. 실제 메시지 구성은 TLS 버전과 연결 조건에 따라 달라진다.

HTTPS는 서버 인증과 통신 암호화를 제공하지만, 웹 애플리케이션 자체의 취약점이나 잘못된 접근 권한까지 자동으로 해결해 주는 것은 아니다.

8. TLS 인증서 오류 분석

HTTPS 접속 실패의 대표적인 원인 중 하나는 인증서 문제다.

인증서 관련 오류가 발생하면 다음 항목을 확인한다.

인증서 만료 여부
접속 도메인과 인증서의 호스트 이름 일치 여부
인증서 체인 구성
서버의 시스템 시간
클라이언트가 신뢰하는 CA 여부
Nginx 또는 웹 서버의 인증서 설정
인증서 갱신 후 서비스에 적용되었는지 여부

8-1. 인증서 정보 확인

openssl s_client \
  -connect www.example.com:443 \
  -servername www.example.com \
  -showcerts

-servername 옵션은 SNI를 지정한다. 여러 도메인이 하나의 IP를 공유하는 서버에서는 정확한 인증서를 확인하는 데 중요하다.

출력에서 인증서 체인과 검증 결과를 확인한다.

인증서의 유효 기간이나 도메인 이름을 별도로 확인하려면 다음과 같이 사용할 수 있다.

echo | openssl s_client \
  -connect www.example.com:443 \
  -servername www.example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

이 명령은 서버가 제공한 인증서의 주체, 발급자, 유효 기간을 출력한다.

단, 인증서 정보가 정상적으로 출력된다는 사실만으로 인증서 체인과 클라이언트의 신뢰 검증까지 모두 성공했다고 볼 수는 없다.

8-2. 인증서 검증 결과 확인

curl -v https://www.example.com

인증서 검증에 실패하면 CA 인증서, 도메인 이름, 유효 기간, 인증서 체인 등을 점검한다.

테스트 목적으로 curl -k를 사용하면 인증서 검증을 생략할 수 있다.

curl -k -v https://www.example.com

그러나 -k는 인증서 검증 실패 원인을 해결하지 않는다. 정상 운영 서비스에서는 인증서 검증을 비활성화하지 말고 원인을 수정해야 한다.

9. 실제 장애 사례 1 — HTTP는 되지만 HTTPS가 안 되는 경우

다음과 같은 상황을 가정하자.

http://192.168.10.100   -> 응답 성공
https://192.168.10.100  -> 접속 실패

HTTP 요청은 성공하지만 HTTPS 요청은 실패한다.

이때는 다음 순서로 확인한다.

9-1. 포트 상태 확인

서버에서 실행한다.

sudo ss -lntp | grep -E ':(80|443)\b'

예를 들어 다음과 같이 출력될 수 있다.

LISTEN 0 511 0.0.0.0:80  0.0.0.0:*

80번 포트만 LISTEN 상태이고 443번 포트가 없다면 HTTPS 서비스를 제공하는 프로세스가 실행 중인지 확인해야 한다.

9-2. 방화벽 확인

Rocky Linux나 RHEL 계열에서 firewalld를 사용하는 경우 다음과 같이 확인한다.

sudo firewall-cmd --list-all

HTTPS 서비스가 허용되지 않았다면 방화벽 정책을 검토한다.

다만 서버 내부 방화벽뿐 아니라 외부 방화벽, 클라우드 보안 그룹, 네트워크 ACL도 확인해야 한다.

9-3. Nginx 설정 확인

sudo nginx -t
sudo systemctl status nginx

Nginx 설정에서 443번 포트의 listen 설정과 인증서 경로를 확인한다.

server {
    listen 443 ssl;
    server_name www.example.com;

    ssl_certificate     /etc/letsencrypt/live/www.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/www.example.com/privkey.pem;
}

위 설정은 구조를 설명하기 위한 예시다. 실제 인증서 경로와 도메인 이름은 환경에 맞게 변경해야 한다.

9-4. 로그 확인

sudo journalctl -u nginx --since "30 minutes ago"

Nginx의 오류 로그도 확인한다.

sudo tail -n 100 /var/log/nginx/error.log

배포판이나 설치 방식에 따라 로그 경로는 달라질 수 있다.

10. 실제 장애 사례 2 — 502 Bad Gateway

시스템 엔지니어가 웹 서비스를 운영할 때 자주 만나는 오류다.

예를 들어 다음과 같은 구조를 사용한다고 가정하자.

Browser
   |
   | HTTPS :443
   v
Nginx
   |
   | HTTP :8000
   v
FastAPI
   |
   v
PostgreSQL

브라우저에서 요청했을 때 다음 응답이 반환된다.

HTTP/1.1 502 Bad Gateway

이 경우 브라우저와 Nginx 사이의 통신은 성공했을 수 있지만, Nginx와 FastAPI 사이의 통신에서 문제가 발생했을 수 있다.

10-1. 백엔드 서비스 상태 확인

FastAPI가 실행 중인 서버에서 확인한다.

sudo ss -lntp | grep ':8000'

포트가 열려 있지 않다면 애플리케이션 프로세스 상태와 로그를 확인한다.

sudo systemctl status <backend-service>

서비스 이름은 실제 환경에 맞게 변경해야 한다.

10-2. 백엔드 직접 호출

Nginx가 백엔드와 같은 서버에서 실행된다면 다음과 같이 확인할 수 있다.

curl -v http://127.0.0.1:8000/

백엔드가 다른 서버에서 실행된다면 실제 업스트림 주소를 사용해야 한다.

curl -v http://192.168.10.200:8000/

10-3. Nginx 업스트림 설정 확인

location /api/ {
    proxy_pass http://127.0.0.1:8000;
}

위 설정은 예시다.

실제 운영 환경에서는 다음 항목을 확인한다.

업스트림 IP 주소와 포트가 올바른가?
백엔드 프로세스가 해당 주소에서 LISTEN 중인가?
Nginx가 백엔드 주소에 접근할 수 있는가?
proxy_pass의 URI 처리 방식이 의도한 경로와 일치하는가?
SELinux 정책이나 방화벽이 연결을 차단하는가?
백엔드가 HTTP를 사용하는지 HTTPS를 사용하는지 일치하는가?

특히 proxy_pass에 경로를 지정하는 방식에 따라 요청 URI가 전달되는 형태가 달라질 수 있다. 경로 접두어가 예상과 다르게 제거되거나 유지되면 특정 API 경로에서 404가 발생할 수 있다.

10-4. Nginx 오류 로그 확인

sudo tail -f /var/log/nginx/error.log

대표적으로 다음과 같은 메시지가 나올 수 있다.

connect() failed (111: Connection refused) while connecting to upstream

이 메시지는 Nginx가 업스트림에 연결하려 했지만 연결이 거부되었음을 나타낸다.

백엔드 서비스가 중단되었거나, 잘못된 포트로 연결하거나, 해당 주소에서 서비스가 LISTEN 중이지 않은 상황 등을 점검한다.

반면 upstream timed out 메시지가 나타난다면 백엔드 응답 지연, 네트워크 문제, 연결 정체 또는 타임아웃 설정 등을 확인해야 한다.

11. 실제 장애 사례 3 — 404 Not Found

404는 요청한 리소스를 찾을 수 없다는 의미다.

하지만 반드시 파일이 없다는 뜻은 아니다.

웹 서버 설정, API 라우팅, 요청 경로, 리버스 프록시의 URI 처리 방식 때문에 발생할 수도 있다.

예를 들어 다음과 같은 주소가 있다고 가정하자.

https://www.example.com/api/users

Nginx가 /api/ 요청을 FastAPI로 전달하도록 설정되어 있다고 하자.

location /api/ {
    proxy_pass http://127.0.0.1:8000;
}

이 구성에서는 일반적으로 요청 URI의 /api/users 경로가 업스트림으로 전달된다.

반면 다음과 같이 설정하면 URI 처리 방식이 달라질 수 있다.

location /api/ {
    proxy_pass http://127.0.0.1:8000/;
}

proxy_pass에 URI 부분이 포함된 경우 일치하는 location 경로가 해당 URI로 치환되는 방식이 적용될 수 있다.

따라서 /api/users가 업스트림에서 /users로 전달되는 구성이 될 수 있다.

이 차이는 FastAPI가 /api/users를 제공하는지, /users를 제공하는지에 따라 결과를 바꿀 수 있다.

장애 분석 시 다음 순서로 확인한다.

클라이언트가 요청한 URL 확인
Nginx의 location 설정 확인
proxy_pass의 URI 처리 방식 확인
백엔드 API 라우트 확인
백엔드에 직접 요청해 결과 비교
Nginx 액세스 로그와 오류 로그 확인

이렇게 하면 URL 경로 문제와 백엔드 애플리케이션 문제를 구분하기 쉽다.

12. tcpdump로 HTTP와 HTTPS 분석하기

HTTP와 HTTPS는 패킷 캡처를 통해 연결 상태를 확인할 수 있다.

다만 HTTPS에서는 일반적으로 HTTP 요청 경로, 헤더, 본문이 TLS로 암호화되므로 tcpdump만으로 전체 HTTP 메시지를 직접 읽을 수는 없다.

12-1. HTTP 80번 포트 캡처

sudo tcpdump -nn -i ens160 'tcp port 80'

특정 서버와의 통신만 확인하려면 다음과 같이 실행한다.

sudo tcpdump -nn -i ens160 'host 192.168.10.100 and tcp port 80'

HTTP/1.x의 평문 통신에서는 패킷 페이로드에 요청 메서드와 헤더 일부가 보일 수 있다.

12-2. HTTPS 443번 포트 캡처

sudo tcpdump -nn -i ens160 'tcp port 443'

이 명령으로 TCP 연결과 TLS 관련 패킷 흐름을 확인할 수 있다.

다음과 같은 상황을 구분하는 데 도움이 된다.

클라이언트 SYN이 서버까지 도달하는가?
서버가 SYN-ACK를 반환하는가?
TCP 연결이 수립되는가?
연결 수립 후 TLS 데이터가 오가는가?
연결이 즉시 종료되는가?

단, TCP 연결이 수립되었다고 해서 TLS Handshake가 성공한 것은 아니다.

12-3. 패킷을 파일로 저장

sudo tcpdump -ni ens160 \
  -s 0 \
  -w /tmp/https-capture.pcap \
  'tcp port 443'

저장한 파일은 Wireshark에서 분석할 수 있다.

HTTPS 연결에서 인증서 교환이나 TLS 오류를 분석할 때는 TLS 버전, SNI, 인증서 관련 메시지 등 캡처에서 확인 가능한 정보를 살펴본다. TLS 버전과 암호화 방식에 따라 관찰 가능한 내용은 달라진다.

실제 HTTP 요청 내용을 확인해야 한다면 애플리케이션 로그, 리버스 프록시 로그 또는 승인된 TLS 복호화 분석 환경을 이용해야 한다.

13. HTTP와 HTTPS 장애 분석 실전 순서

웹 서비스에 접속할 수 없을 때는 아래 순서로 확인한다.

1단계. DNS 확인

dig www.example.com

도메인이 예상한 IP 주소로 해석되는지 확인한다.

2단계. TCP 포트 확인

nc -zv www.example.com 443

TCP 연결이 가능한지 확인한다.

연결이 거부되거나 시간 초과되는 경우에는 서버 포트, 방화벽, 라우팅 등을 추가로 점검한다.

3단계. HTTP 응답 확인

curl -v http://www.example.com

HTTP 요청이 어떤 응답을 받는지 확인한다.

4단계. HTTPS 및 인증서 확인

curl -v https://www.example.com

TLS Handshake와 인증서 검증 단계에서 오류가 발생하는지 확인한다.

필요하면 다음 명령어로 인증서 정보를 점검한다.

openssl s_client \
  -connect www.example.com:443 \
  -servername www.example.com

5단계. 서버의 포트 상태 확인

sudo ss -lntp

웹 서버와 백엔드가 올바른 주소와 포트에서 LISTEN 중인지 확인한다.

6단계. 서비스 로그 확인

sudo journalctl -u nginx --since "30 minutes ago"

애플리케이션 로그도 함께 확인한다.

7단계. 패킷 흐름 확인

sudo tcpdump -nn -i ens160 'tcp port 80 or tcp port 443'

패킷이 서버에 도착하는지, 응답이 반환되는지 확인한다.

이 과정을 통해 장애가 DNS, TCP, TLS, HTTP, Nginx, 백엔드 애플리케이션 중 어느 계층에서 발생하는지 좁혀갈 수 있다.

14. 시스템 엔지니어가 기억해야 할 핵심

HTTP와 HTTPS 장애 분석에서 가장 중요한 것은 계층별로 문제를 구분하는 것이다.

DNS
 |
 v
IP Routing
 |
 v
TCP Connection
 |
 v
TLS Handshake
 |
 v
HTTP Request / Response
 |
 v
Reverse Proxy
 |
 v
Backend Application
 |
 v
Database / External Dependency

각 단계는 서로 연결되어 있지만 동일한 문제는 아니다.

예를 들어 HTTPS 접속 실패는 인증서 오류일 수도 있지만, 실제로는 TCP 443번 포트에 연결할 수 없는 문제일 수도 있다.

502 오류는 Nginx와 백엔드 사이의 연결 문제일 수 있지만, 백엔드가 느리거나 업스트림 설정이 잘못된 경우에도 발생할 수 있다.

따라서 하나의 명령어 결과만 보고 원인을 확정하지 말고 다음 증거를 조합해야 한다.

dig: DNS 조회 결과
ip route: 라우팅 경로
nc: TCP 포트 연결
ss: 서버 소켓 상태
curl: HTTP 및 HTTPS 요청 결과
openssl s_client: TLS 연결과 인증서 확인
tcpdump: 실제 패킷 흐름
Nginx 및 애플리케이션 로그: 요청 처리 과정과 오류 원인

이 도구들을 함께 사용하면 브라우저에서 보이는 오류를 실제 서버와 네트워크의 상태로 연결해 분석할 수 있다.

마무리

이번 편에서는 HTTP와 HTTPS의 기본 구조, HTTP 요청·응답, 상태 코드, TLS 인증서, Linux 명령어를 이용한 장애 분석을 살펴보았다.

시스템 엔지니어는 단순히 웹 서버 프로세스가 실행 중인지 확인하는 데서 멈추면 안 된다.

DNS가 정상인지, TCP 연결이 가능한지, TLS Handshake가 성공하는지, HTTP 요청이 올바르게 처리되는지, 리버스 프록시와 백엔드 사이에 문제가 없는지 단계별로 확인해야 한다.

이러한 분석 방식은 Nginx, Apache, FastAPI, Spring Boot, Docker, Kubernetes 기반 웹 서비스에서도 폭넓게 활용할 수 있다.

다음 편에서는 TLS/SSL의 동작 원리와 인증서 체인, 공개키·개인키, TLS Handshake의 실제 과정을 더 깊이 다룬다. HTTPS 연결이 실패할 때 인증서와 암호화 연결을 어떻게 분석하는지 실전 중심으로 살펴보겠다.

아직 댓글이 없습니다.

로그인 후 댓글을 남길 수 있습니다.