포트포워딩이 안 될 때 확인할 것

1. 같은 IP를 검사하고 있나요?

PPORT는 접속한 브라우저의 공인 IP만 검사합니다. NAS를 확인하려면 NAS와 같은 인터넷 회선을 사용하는 PC에서 페이지를 열고 표시된 IP를 공유기 WAN 주소와 비교하세요. VPN·프록시를 사용하면 사이트가 보는 IP가 달라질 수 있습니다. 모바일 데이터를 켠 휴대전화에서 접속하면 보통 집이 아니라 휴대전화 통신망의 IP를 검사하게 됩니다.

외부 TCP 연결은 PPORT 서버가 시도하므로, 결과는 검사한 시점과 경로에서의 상태입니다. NAS가 프록시나 별도 회선을 쓰는 경우에는 IP가 같아 보여도 실제 대상이 다를 수 있습니다. 표시된 IP, IP 버전, 외부 포트, 검사 시각을 함께 기록해 두세요.

2. 프로그램이 실제로 기다리고 있나요?

예를 들어 NAS의 내부 서비스가 TCP 8080을 쓴다고 가정합니다. 서버에서 대기 소켓을 확인하세요. 127.0.0.1:8080은 그 장치 안에서만 받는 설정입니다. 0.0.0.0:8080은 모든 IPv4 인터페이스에 바인딩했다는 뜻이지만 방화벽 허용이나 인터넷 공개까지 뜻하지 않습니다. [::]:8080의 IPv4 수용 여부는 OS 설정에 따라 다릅니다.

아래 출력에 대기 항목이 없으면 공유기보다 프로그램 실행·포트 설정을 먼저 확인합니다. LISTENING 행의 마지막 숫자는 Windows 프로세스 ID입니다. 명령은 해당 서비스를 실행하는 장치에서 실행해야 합니다.

Get-NetTCPConnection -State Listen -LocalPort 8080

netstat -ano | findstr "LISTENING" | findstr /C:":8080 "

ss -lnt 'sport = :8080'

lsof -nP -iTCP:8080 -sTCP:LISTEN

3. 내부망에서도 접근할 수 있나요?

같은 LAN의 다른 장치에서 서버의 내부 IP와 내부 포트로 접속합니다. 내부 연결도 실패하면 호스트 방화벽, 서비스 바인딩, VLAN·무선 격리부터 확인하세요. 내부 연결 성공은 서버와 LAN 경로를 좁혀 주지만 공유기의 외부 전달 규칙은 아직 검증하지 못합니다.

외부 18080 → 내부 192.168.0.20:8080 규칙이라면 PPORT에는 18080을 입력합니다. 서버 대기 상태는 8080으로 확인합니다. DHCP로 내부 주소가 바뀌면 규칙이 다른 장치를 가리킬 수 있으므로 주소 예약도 확인하세요.

4. 공유기 밖에 NAT가 더 있나요?

공유기 WAN IPv4가 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 또는 100.64.0.0/10이라면 공유기 위에 NAT가 하나 더 있을 수 있습니다. 앞의 세 대역은 사설 주소, 마지막은 통신사 공유 주소 대역입니다. 이때는 상위 공유기나 통신사에 외부에서 들어오는 연결이 가능한지 문의합니다.

직접 관리하는 이중 공유기라면 각 전달 경로가 맞아야 합니다. 통신사 NAT라면 집 공유기 설정만으로 외부 유입 경로가 만들어지지 않을 수 있습니다. IPv6는 IPv4 포트포워딩과 분리해서 대상 전역 주소와 방화벽을 확인하세요.

5. 결과를 다음 행동으로 연결하기

OPEN이면 TCP 연결이 성립한 것이고, 웹 로그인·인증서·파일 전송까지 정상이라는 뜻은 아닙니다. CLOSED는 대상이 연결을 거부했다는 뜻이고, TIMEOUT은 제한 시간 안에 연결이 완료되지 않았다는 뜻입니다. 어느 쪽이든 원인이 되는 구간은 위의 1~4단계 순서로 좁혀 갑니다.

한 번만 실패한 결과보다 시각·IP·포트·설정 변경을 함께 기록한 비교가 유용합니다. 대기 소켓과 LAN 접속이 정상인데 외부만 실패하면 전달 규칙과 상위 네트워크를 확인하세요. 방화벽 전체를 끄거나 모든 포트를 공개하는 대신 필요한 TCP 포트와 접근 범위만 조정합니다.

Windows: LISTENING인데 외부 접속이 안 될 때

1. 증상

   PPORT에서 외부 TCP 8080을 검사하면 TIMEOUT이나 CLOSED가 나옵니다. 서비스 PC의 브라우저에서는 http://localhost:8080 이 정상으로 열립니다. 공유기에는 외부 8080 → 192.168.0.x:8080 규칙이 있습니다.

2. 환경

   Windows 11 Pro와 PowerShell 5.1, 서비스 PC의 LAN 주소 192.168.0.x(끝자리는 가림), 서비스 포트 TCP 8080입니다. 아래 ‘실측’ 출력은 Python 내장 웹 서버를 127.0.0.1에만 묶어 같은 증상을 재현한 결과입니다. 공유기와 외부 검사 부분은 설명용 설정입니다.

   python -m http.server 8080 --bind 127.0.0.1

3. 확인

   서비스 PC에서 대기 주소를 먼저 확인합니다. 그다음 같은 PC에서 루프백 주소와 LAN 주소로 각각 연결해 봅니다. LAN 주소 연결은 다른 기기 없이도 시험할 수 있습니다.

   Get-NetTCPConnection -State Listen | Where-Object LocalPort -EQ 8080 | Select-Object LocalAddress,LocalPort,OwningProcess

   netstat -ano | findstr "LISTENING" | findstr /C:":8080 "

   Test-NetConnection -ComputerName 127.0.0.1 -Port 8080 | Select-Object RemoteAddress,RemotePort,TcpTestSucceeded
   Test-NetConnection -ComputerName 192.168.0.x -Port 8080 | Select-Object RemoteAddress,RemotePort,PingSucceeded,TcpTestSucceeded

4. 출력과 해석

   PS> Get-NetTCPConnection -State Listen | Where-Object LocalPort -EQ 8080 | Select-Object LocalAddress,LocalPort,OwningProcess
   
   LocalAddress LocalPort OwningProcess
   ------------ --------- -------------
   127.0.0.1         8080         26752
   
   C:\> netstat -ano | findstr "LISTENING" | findstr /C:":8080 "
     TCP    127.0.0.1:8080         0.0.0.0:0              LISTENING       26752
   
   PS> Test-NetConnection -ComputerName 127.0.0.1 -Port 8080 | Select-Object RemoteAddress,RemotePort,TcpTestSucceeded
   
   RemoteAddress RemotePort TcpTestSucceeded
   ------------- ---------- ----------------
   127.0.0.1           8080             True
   
   PS> Test-NetConnection -ComputerName 192.168.0.x -Port 8080 | Select-Object RemoteAddress,RemotePort,PingSucceeded,TcpTestSucceeded
   TCP connect to (192.168.0.x : 8080) failed
   
   RemoteAddress RemotePort PingSucceeded TcpTestSucceeded
   ------------- ---------- ------------- ----------------
   192.168.0.x         8080          True            False

   LocalAddress가 127.0.0.1입니다. 이 프로그램은 루프백 인터페이스에서만 연결을 받습니다. 그래서 127.0.0.1로 연결하면 True, 같은 PC의 LAN 주소로 연결하면 False가 나옵니다.

   PingSucceeded가 True이므로 192.168.0.x 주소 자체는 응답합니다. 원인은 회선이나 공유기가 아니라 프로그램의 대기 주소입니다. 이 상태에서는 방화벽이나 포워딩 규칙을 바꿔도 외부 연결이 성공하지 않습니다.

5. 수정

   프로그램 설정에서 대기 주소를 LAN 주소(192.168.0.x)나 0.0.0.0으로 바꾸고 다시 시작합니다. 0.0.0.0은 VPN·가상 어댑터를 포함한 모든 IPv4 인터페이스에서 연결을 받습니다. 필요한 주소만 지정하면 공개 범위가 좁아집니다.

   Windows 방화벽은 다른 기기에서 오는 연결도 검사합니다. 먼저 현재 네트워크 프로필을 확인합니다. NetworkCategory가 Public이면 Private 프로필 규칙은 적용되지 않습니다. 프로그램을 처음 실행할 때 방화벽 경고 창을 취소했다면 그 프로그램의 차단 규칙이 생겼을 수 있고, 차단 규칙은 허용 규칙보다 우선합니다. 그다음 관리자 PowerShell에서 이 포트만 허용합니다. LAN 안에서만 쓸 서비스라면 -RemoteAddress LocalSubnet을 추가해 범위를 줄입니다.

   python -m http.server 8080 --bind 192.168.0.x

   Get-NetConnectionProfile | Select-Object InterfaceAlias,NetworkCategory
   Get-NetFirewallApplicationFilter | Where-Object Program -Like "*python*" | Get-NetFirewallRule | Select-Object DisplayName,Profile,Action,Enabled
   New-NetFirewallRule -DisplayName "Test web TCP 8080" -Direction Inbound -Protocol TCP -LocalPort 8080 -Action Allow -Profile Private

6. 재확인

   대기 주소와 LAN 주소 연결을 다시 확인합니다. LocalAddress가 192.168.0.x이고 TcpTestSucceeded가 True면 PC 쪽 조건은 해결됐습니다.

   같은 회선의 PC 브라우저에서 PPORT를 열고 외부 포트 8080을 검사합니다. OPEN이면 완료입니다. LAN 연결은 되는데 PPORT만 TIMEOUT이면 남은 구간은 공유기 경로이므로 포트포워딩 가이드의 사례로 넘어갑니다.

   Get-NetTCPConnection -State Listen | Where-Object LocalPort -EQ 8080 | Select-Object LocalAddress,LocalPort,OwningProcess
   Test-NetConnection -ComputerName 192.168.0.x -Port 8080 | Select-Object RemoteAddress,RemotePort,TcpTestSucceeded

   LocalAddress LocalPort OwningProcess
   ------------ --------- -------------
   192.168.0.x       8080         35120
   
   RemoteAddress RemotePort TcpTestSucceeded
   ------------- ---------- ----------------
   192.168.0.x         8080             True

Ubuntu/Linux: active인데 외부 접속이 안 될 때

1. 증상

   클라우드 VM의 웹사이트가 서버 안에서는 응답하는데 외부 브라우저에서는 열리지 않습니다. systemctl은 nginx와 앱 서비스를 모두 active로 표시합니다.

2. 환경

   OCI의 Ubuntu 24.04 VM입니다. Nginx가 외부 80/443을 받고, 앱은 127.0.0.1:8000에서 Nginx의 요청만 받습니다. PPORT 운영 서버와 같은 구성입니다.

   ‘실측’ ss 출력은 2026-10-12에 PPORT 운영 서버에서 확인한 값입니다. 방화벽 출력은 OCI Ubuntu 이미지에 들어 있는 기본 iptables 규칙 형태의 설명용 예시입니다. example.com은 자신의 도메인으로 바꿉니다.

3. 확인

   대기 상태 → 서버 안의 HTTPS 응답 → VM 방화벽 순서로 봅니다. --resolve는 DNS와 외부 경로를 거치지 않고 이 서버의 Nginx에 같은 도메인으로 요청합니다.

   sudo ss -ltnp | grep -E ':8000|:80 |:443 '
   curl -sS -o /dev/null -w '%{http_code}\n' --resolve example.com:443:127.0.0.1 https://example.com/
   sudo ufw status
   sudo iptables -S INPUT

4. 출력과 해석

   $ sudo ss -ltnp | grep -E ':8000|:80 |:443 '
   LISTEN 0      511          0.0.0.0:443       0.0.0.0:*    users:(("nginx",pid=2796421,fd=9),("nginx",pid=2796419,fd=9),("nginx",pid=924555,fd=9))
   LISTEN 0      2048       127.0.0.1:8000      0.0.0.0:*    users:(("gunicorn",pid=2931560,fd=3),("gunicorn",pid=998637,fd=3),("gunicorn",pid=998629,fd=3))
   LISTEN 0      511          0.0.0.0:80        0.0.0.0:*    users:(("nginx",pid=2796421,fd=7),("nginx",pid=2796419,fd=7),("nginx",pid=924555,fd=7))
   LISTEN 0      511             [::]:443          [::]:*    users:(("nginx",pid=2796421,fd=10),("nginx",pid=2796419,fd=10),("nginx",pid=924555,fd=10))
   LISTEN 0      511             [::]:80           [::]:*    users:(("nginx",pid=2796421,fd=8),("nginx",pid=2796419,fd=8),("nginx",pid=924555,fd=8))

   $ curl -sS -o /dev/null -w '%{http_code}\n' --resolve example.com:443:127.0.0.1 https://example.com/
   200
   $ sudo ufw status
   Status: inactive
   $ sudo iptables -S INPUT
   -P INPUT ACCEPT
   -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
   -A INPUT -p icmp -j ACCEPT
   -A INPUT -i lo -j ACCEPT
   -A INPUT -p udp -m udp --sport 123 -j ACCEPT
   -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
   -A INPUT -j REJECT --reject-with icmp-host-prohibited

   Nginx는 0.0.0.0과 [::]의 80/443에서, 앱은 127.0.0.1:8000에서 대기합니다. 8000이 루프백에만 열린 것은 의도한 구성이며 외부에 열 필요가 없습니다. 서버 안의 --resolve 요청이 200이므로 Nginx·인증서·앱은 동작합니다. 남은 구간은 서버 밖에서 들어오는 경로입니다.

   UFW가 inactive여도 iptables 규칙은 동작합니다. 마지막 REJECT 앞에서 허용하는 새 TCP 연결은 22번뿐이라 80/443 연결은 거부됩니다. 이 경우 외부 curl은 바로 실패합니다. 몇 초 기다린 뒤 시간 초과로 끝난다면 VM에 닿기 전, OCI 보안 목록이나 NSG에서 패킷이 버려졌을 가능성이 큽니다.

5. 수정

   REJECT보다 앞에 80/443 허용 규칙을 넣고 저장합니다. 규칙 번호는 -P 줄을 빼고 -A 줄을 위에서부터 셉니다. 예시에서 REJECT는 6번이므로 6번 위치에 넣습니다. netfilter-persistent save를 하지 않으면 재부팅 후 규칙이 사라집니다.

   OCI 콘솔에서는 인스턴스 서브넷의 보안 목록 또는 VNIC에 연결된 NSG에 TCP 80/443 수신 규칙을 추가합니다. 백엔드 8000과 데이터베이스 포트는 추가하지 않습니다.

   sudo iptables -I INPUT 6 -p tcp -m state --state NEW --dport 80 -j ACCEPT
   sudo iptables -I INPUT 6 -p tcp -m state --state NEW --dport 443 -j ACCEPT
   sudo netfilter-persistent save

6. 재확인

   허용 규칙이 REJECT보다 위에 있고 외부 요청이 200을 받으면 완료입니다. 서버 밖의 PC가 없다면 PPORT의 HTTP 상태코드 확인과 SSL 인증서 확인 도구를 사용합니다. 두 도구는 PPORT 서버에서 공개 80/443으로 접속합니다.

   sudo iptables -S INPUT

   curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/

   $ sudo iptables -S INPUT
   -P INPUT ACCEPT
   -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
   -A INPUT -p icmp -j ACCEPT
   -A INPUT -i lo -j ACCEPT
   -A INPUT -p udp -m udp --sport 123 -j ACCEPT
   -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
   -A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
   -A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
   -A INPUT -j REJECT --reject-with icmp-host-prohibited
   $ curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/
   200

OPEN인데 웹사이트가 작동하지 않을 때

1. 증상

   PPORT에서 443은 OPEN인데 브라우저에는 502 Bad Gateway가 표시됩니다.

2. 환경

   Nginx가 443에서 TLS를 처리하고, 앱(systemd 서비스 myapp)은 127.0.0.1:8000에서 받습니다. Ubuntu 24.04 기준 설명용 예시입니다. example.com과 192.0.2.10은 자신의 도메인과 서버 IP로 바꿉니다.

3. 확인

   OPEN은 TCP 연결까지 확인한 결과입니다. 이후 계층은 바깥에서 안쪽으로 확인합니다. --resolve는 DNS가 다른 서버를 가리킬 가능성을 배제하고, 같은 도메인의 Host와 SNI로 지정한 서버에 요청합니다.

   curl -sS -I --resolve example.com:443:192.0.2.10 https://example.com/

   curl -sS -i http://127.0.0.1:8000/
   sudo tail -n 1 /var/log/nginx/error.log

4. 출력과 해석

   $ curl -sS -I --resolve example.com:443:192.0.2.10 https://example.com/
   HTTP/1.1 502 Bad Gateway
   Server: nginx
   
   $ curl -sS -i http://127.0.0.1:8000/
   curl: (7) Failed to connect to 127.0.0.1 port 8000 after 0 ms: Couldn't connect to server
   
   $ sudo tail -n 1 /var/log/nginx/error.log
   2026/10/12 10:15:32 [error] 1234#1234: *56 connect() failed (111: Connection refused) while connecting to upstream, client: 198.51.100.7, server: example.com, request: "HEAD / HTTP/1.1", upstream: "http://127.0.0.1:8000/", host: "example.com"

   외부 요청은 Nginx까지 도달해 502를 받았으므로 TCP와 TLS는 정상입니다. 서버 안에서 8000으로 직접 연결하면 거부되고, Nginx 로그에도 upstream 연결 거부(111: Connection refused)가 남았습니다. 앱이 8000에서 대기하지 않는 상태입니다. curl 오류 문구는 버전마다 조금 다르지만 (7)은 연결 실패를 뜻합니다.

   서버 안의 8000 요청은 200인데 외부만 502라면 앱이 아니라 Nginx 설정을 봅니다. proxy_pass의 포트와 http/https가 앱과 맞는지, 로그에 upstream timed out(110)이 남는지 확인합니다.

5. 수정

   서비스 상태와 최근 로그에서 앱이 멈춘 이유를 찾습니다. 예시에서는 환경 변수가 없어 시작 직후 종료됐습니다. 설정 파일에 값을 넣고 서비스를 다시 시작합니다.

   systemctl status myapp --no-pager
   sudo journalctl -u myapp -n 20 --no-pager

   $ systemctl status myapp --no-pager
   × myapp.service - Example web app
        Loaded: loaded (/etc/systemd/system/myapp.service; enabled; preset: enabled)
        Active: failed (Result: exit-code) since Mon 2026-10-12 10:14:58 KST; 1min 12s ago
   
   $ sudo journalctl -u myapp -n 20 --no-pager
   Oct 12 10:14:58 web1 myapp[2210]: RuntimeError: DATABASE_URL is not set
   Oct 12 10:14:58 web1 systemd[1]: myapp.service: Main process exited, code=exited, status=1/FAILURE
   Oct 12 10:14:58 web1 systemd[1]: myapp.service: Failed with result 'exit-code'.

   sudoedit /etc/myapp.env
   sudo systemctl restart myapp

6. 재확인

   앱이 8000에서 다시 응답하는지 확인한 뒤 외부 요청을 반복합니다. 둘 다 200이면 완료입니다. 서버 밖에서는 PPORT의 HTTP 상태코드 확인으로 응답 코드를, SSL 인증서 확인으로 인증서 이름과 만료일을 확인할 수 있습니다.

   curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8000/
   curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/

   200
   200

범위와 한계

이 절차는 본인이 관리하는 TCP 서비스에 적용합니다. UDP 서비스, VPN 터널, 리버스 프록시의 응용 계층 장애는 별도 진단이 필요합니다. 서비스가 의도적으로 외부 접속을 막는 경우에는 공개하지 않는 설정이 맞을 수 있습니다.

이 글과 함께 쓰는 도구