443 포트는 열어 둬야 할까

443은 HTTPS가 쓰는 포트입니다. 주소창에 https://example.com을 입력하면 브라우저는 서버 IP의 443 포트로 TCP 연결을 열고, 그 위에서 TLS를 시작합니다. 그러니:

  • HTTPS로 웹사이트나 API를 서비스하는 서버라면 443은 인터넷에 열려 있어야 합니다. 안전하게 피해 갈 방법은 없습니다. 그게 서버가 하는 일이니까요.
  • 내 노트북, PC, 가정용 공유기이고 아무것도 서비스하지 않는다면 들어오는 443을 열 필요가 없습니다. 웹 서핑은 다른 서버의 443으로 나가는 연결입니다. 방화벽은 나가는 연결과 그에 대한 응답을 들어오는 규칙 없이도 허용합니다.

‘방화벽 443 포트’를 둘러싼 혼란은 대개 이 차이에서 옵니다. PC에서 들어오는 443을 연다고 웹사이트가 더 잘 열리지는 않습니다. 그 PC에서 HTTPS 연결을 받아야 하는 프로그램이 있을 때만 의미가 있습니다.

443이 열려 있으면 위험할까요? 다른 포트보다는 덜합니다. 누구나 열려 있을 거라 예상하는 포트이고, 웹 서버는 원래 그걸 위해 만들어졌습니다. 위험은 그 뒤의 소프트웨어에 있습니다. 최신으로 유지하고, 나만 쓰는 관리 화면을 거기에 공개하지 마세요. 같은 서버의 다른 포트를 점검하고 있다면 위험한 열린 포트를 보세요.

서버 안이 아니라 바깥에서 확인하기

서버에서는 ‘열려’ 있는 포트도 인터넷에서는 닫혀 있을 수 있습니다. 다른 곳에서 테스트하세요.

포트 점검은 내 네트워크 바깥에서 연결합니다. 그 포트만 보려면 example.com:443을, 80·443·8080·8443을 포함한 흔한 포트 15개를 보려면 호스트명만 넣으세요. 포트마다 3초를 기다립니다. ‘열림’은 TCP 연결이 맺어졌다는 뜻이고, ‘닫힘’은 거부와 무응답을 모두 포함합니다. 이 도구는 둘을 구분하지 않습니다.

다른 기계에서라면 차이를 볼 수 있습니다.

nc -vz -w 5 example.com 443
# Connection to example.com 443 port [tcp/https] succeeded!
# nc: connect to example.com port 443 (tcp) failed: Connection refused
# nc: connect to example.com port 443 (tcp) timed out: Operation now in progress

Windows에서는:

Test-NetConnection example.com -Port 443
# TcpTestSucceeded : True

nmap -Pn -p 443 example.com은 open, closed, filtered로 답하고, 같은 세 경우에 대응합니다.

읽는 법은 이렇습니다.

  • 바로 거부됨. 패킷은 서버에 닿았고 OS가 “여기 아무도 없음”이라고 답했습니다. 그 주소의 443에서 듣는 프로그램이 없거나, 방화벽이 REJECT로 설정돼 있습니다. 리스너부터 보세요.
  • 시간 초과. 가는 길에 무언가가 패킷을 버렸습니다. 방화벽, 클라우드 보안 그룹, 공유기, 또는 IP가 틀렸습니다. 네트워크 층부터 보세요.
  • 열려 있는데 브라우저는 여전히 실패. 포트 문제가 아닙니다. 맨 아래로 가세요.

올바른 주소를 테스트하고 있는지도 확인하세요. dig +short example.com A와 dig +short example.com AAAA가 방문자가 실제로 가는 주소입니다. AAAA 레코드가 있다면 IPv6도 따로 테스트하세요(nc -6 -vz example.com 443). 브라우저는 IPv6가 있으면 그쪽을 먼저 쓰고 실패할 때만 IPv4로 넘어가는데, IPv6 경로만 방화벽 설정이 다른 경우가 흔합니다.

443에서 듣는 프로그램이 없음

서버에서:

sudo ss -ltnp 'sport = :443'
State  Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0      511          0.0.0.0:443       0.0.0.0:*     users:(("nginx",pid=812,fd=7))
LISTEN 0      511             [::]:443          [::]:*     users:(("nginx",pid=812,fd=8))

결과가 비어 있으면 443에서 연결을 받는 프로세스가 없는 것이고, 방화벽을 아무리 고쳐도 해결되지 않습니다. 흔한 이유는 이렇습니다.

  • 웹 서버가 실행 중이 아니거나 시작에 실패함. systemctl status nginx와 journalctl -u nginx -n 50이 대개 이유를 알려 줍니다. 인증서 파일이 없는 경우가 대표적입니다.
  • 실행 중이지만 80 포트만 설정돼 있음. nginx라면 실제 적용된 설정에 listen 443 ssl; 줄이 있는지 보세요. sudo nginx -T | grep -n 'listen'. Apache라면 Listen 443(보통 ports.conf에 있고 mod_ssl과 함께 로드)과 <VirtualHost *:443> 블록이 필요합니다.
  • 애플리케이션이 443에 직접 바인드하려는데 권한이 없음. 리눅스에서 1024 미만 포트는 root나 CAP_NET_BIND_SERVICE 권한이 필요합니다. 일반 사용자로 띄운 Node나 Python 앱은 EACCES나 permission denied로 실패합니다. 앞에 리버스 프록시를 두거나 권한을 주세요.
  • 다른 프로세스가 이미 443을 잡고 있어서 웹 서버가 address already in use로 실패함. ss로 어느 프로세스인지 볼 수 있습니다.

듣고는 있지만 방문자가 오는 곳이 아님

줄이 있느냐만큼 Local Address 칸이 중요합니다.

  • 127.0.0.1:443이나 [::1]:443은 그 기계 자신의 연결만 받습니다. 앱을 listen('127.0.0.1')로 설정했거나 Docker 포트를 -p 127.0.0.1:443:443으로 게시한 경우에 흔합니다. 0.0.0.0(또는 공인 인터페이스)에 바인드하거나, 공개적으로 듣는 프록시를 앞에 두세요.
  • 0.0.0.0:443 없이 [::]:443만 있음. 이것이 IPv4까지 받는지는 소프트웨어마다 다릅니다. nginx는 기본이 ipv6only=on이라 listen [::]:443 ssl;만 있으면 IPv4는 닫혀 있습니다. listen 443 ssl;도 추가하세요.
  • 컨테이너가 Docker 안에서는 듣고 있지만 게시되지 않음. 게시돼 있으면 docker ps에 0.0.0.0:443->443/tcp가 보입니다. -p(Compose라면 ports:)가 없으면 호스트 바깥에서는 닿을 수 없습니다.

서버 방화벽

0.0.0.0:443에서 듣는 프로그램이 있는데 바깥 테스트가 시간 초과라면, 다음 용의자는 운영체제의 방화벽입니다.

# Ubuntu / Debian (ufw)
sudo ufw status verbose
sudo ufw allow 443/tcp

# RHEL, Rocky, Fedora (firewalld)
sudo firewall-cmd --list-all
sudo firewall-cmd --permanent --add-service=https && sudo firewall-cmd --reload

# iptables 직접 (이것만으로는 재부팅 후 사라짐)
sudo iptables -L INPUT -n -v --line-numbers
sudo iptables -I INPUT -p tcp --dport 443 -j ACCEPT

Windows Server에서는:

New-NetFirewallRule -DisplayName "HTTPS in" -Direction Inbound -Protocol TCP -LocalPort 443 -Action Allow

iptables -L -v의 패킷 카운터를 보세요. 테스트할 때마다 카운터가 올라가는 DROP 규칙이 있다면 그게 답입니다. IPv6도 덮여 있는지 확인하세요. ip6tables(nftables라면 inet 패밀리)는 별도 규칙 세트라, IPv4 규칙만 있으면 IPv6는 닫혀 있습니다.

클라우드 방화벽

클라우드 서버에는 기계 바깥에 방화벽이 하나 더 있고, 설정이 맞는 서버가 시간 초과를 내는 가장 흔한 이유입니다.

  • AWS: 인스턴스의 보안 그룹에 TCP 443을 0.0.0.0/0(IPv6는 ::/0)에서 받는 인바운드 규칙이 필요합니다. 서브넷에 별도 네트워크 ACL이 있다면, NACL은 상태를 기억하지 않으므로(stateless) 인바운드 443과 함께 응답용 아웃바운드 임시 포트(1024-65535)도 허용해야 합니다.
  • Google Cloud: tcp:443을 허용하는 VPC 방화벽 규칙. 인스턴스를 만들 때 ‘HTTPS 트래픽 허용’에 체크하면 기본 규칙이 매칭하는 https-server 네트워크 태그가 붙습니다. 태그나 대상이 맞지 않는 규칙은 그 인스턴스에 적용되지 않습니다.
  • Azure: NIC나 서브넷의 네트워크 보안 그룹(NSG)에 거부 규칙보다 우선순위가 높은 인바운드 규칙.
  • Oracle Cloud: VCN 보안 목록(security list)이나 NSG, 그리고 인스턴스 자체. Oracle의 플랫폼 이미지는 자체적으로 제한적인 서버 방화벽 규칙을 갖고 나오므로, 보안 목록만 열어서는 안 되는 경우가 많습니다.

서버가 로드밸런서 뒤에 있다면 로드밸런서에 443 리스너가 있어야 하고, 서버의 보안 그룹은 로드밸런서를 허용해야 합니다. 방문자는 서버의 443에 직접 닿지 않습니다.

NAT, 포트 포워딩, ISP

집이나 사무실의 공유기 뒤에 있는 서버라면:

  • 공유기에 외부 443에서 서버 내부 IP의 443으로 가는 포트 포워딩이 있어야 합니다. 없으면 공유기는 들어온 연결을 어디로 보낼지 모릅니다.
  • 일부 공유기는 원격 관리에 443을 직접 쓰고, 포워딩과 충돌합니다. 원격 관리를 끄거나 포트를 옮기세요.
  • 일부 가정용 ISP는 들어오는 80·443을 막습니다. 나머지가 다 맞아도 바깥 테스트는 시간 초과가 납니다. ISP 약관이나 고객센터에서 확인할 수 있습니다.
  • 공유기 관리 화면의 WAN 주소가 내 공인 IP와 다르거나 100.64.0.0/10 대역이라면 CGNAT 뒤에 있는 것입니다. 들어오는 연결은 아예 닿을 수 없습니다. ISP에 공인 IP를 요청하거나, 나가는 연결로 동작하는 터널 서비스를 쓰세요.

443은 열려 있는데 HTTPS가 여전히 안 될 때

그렇다면 문제는 TCP보다 위에 있습니다.

  • curl -v https://example.com이 wrong version number를 낸다면, 443에서 무언가가 듣고 있지만 평문 HTTP로 말하고 있습니다. nginx라면 ssl 없이 listen 443;으로 적은 경우입니다.
  • 인증서 오류, 핸드셰이크 실패, 프로토콜 오류라면 SSL 점검으로 서버가 실제로 내놓는 인증서와 TLS 버전을 보세요.
  • 리다이렉트 루프나 오류 상태 코드라면 HTTP 점검이 리다이렉트를 따라가며 응답을 하나씩 보여 줍니다.

Cloudflare 뒤에 있는 사이트라면 엣지의 443은 언제나 열려 있고, 진짜 질문은 Cloudflare가 원 서버에 닿느냐입니다. 우리 포트 점검은 Cloudflare 주소를 테스트하지 않고(연결을 열 수 없으므로) 그렇다고 알려 줍니다. 대신 원 서버 IP를 테스트하고, Cloudflare 오류 화면이 뜬다면 Cloudflare 522나 525를 보세요.

내 네트워크에서만 443이 안 될 때

바깥 점검은 열림이고 휴대폰 데이터로는 사이트가 열리는데 사무실이나 집 회선에서만 안 된다면, 막힌 곳은 내 쪽입니다.

  • 허용된 사이트만 통과시키거나 HTTPS를 검사하는 회사 방화벽·프록시.
  • HTTPS를 가로채는 백신이나 ‘웹 보호’ 프로그램.
  • 이름을 다른 주소로 보내는 VPN이나 DNS 필터.

브라우저 쪽 진단은 ERR_CONNECTION_TIMED_OUT, ERR_CONNECTION_REFUSED, ERR_CONNECTION_RESET에 정리돼 있습니다.

고친 다음에

IPv4와 IPv6 모두 바깥 점검을 다시 하고, curl -v https://example.com -o /dev/null로 Connected to, TLS 핸드셰이크, HTTP 상태 코드가 차례로 나오는지 확인하세요. iptables를 직접 바꿨다면 다음 재부팅에 사라지지 않게 규칙을 저장하세요(Debian·Ubuntu는 netfilter-persistent save, 다른 배포판은 그에 해당하는 방법).

내 도메인에서 바로 확인

무료, 가입 불필요. 이 가이드가 다루는 항목을 바로 검사하고 조치 방법을 알려드립니다.