OCI 콘솔에서 확인:

Networking → Virtual Cloud Networks → VCN → Subnets → Security Lists
→ Ingress Rules 확인

이 사례에서는 80 포트 규칙이 보였지만, 규칙 존재만으로 해당 연결의 허용이나 도달성을 확정할 수 없습니다. 실제 VNIC의 subnet에 연결된 Security Lists와 VNIC가 속한 모든 NSGs의 허용 규칙을 함께 보고, 방향·출발지/목적지·프로토콜·포트·stateful/stateless 처리와 반환 트래픽 조건을 대조해야 합니다.
실제 적용되는 라우팅도 별도로 확인해야 하며, 엔드포인트에 ZPR 보안 속성이 적용되어 있다면 ZPR 정책의 허용 조건도 충족해야 합니다.

# firewalld 서비스 확인
sudo firewall-cmd --list-services
# dhcpv6-client http https ssh ← 서비스 목록 예시; 활성 zone/규칙은 별도 확인

# iptables 확인
sudo iptables -L -n | grep -E "80|DROP|REJECT"
# 사례의 필터링된 목록 예시; 전체 정책/규칙 판정 불가

위 출력만으로는 해당 연결을 호스트 방화벽이 허용하는지 확정할 수 없습니다. zone을 지정하지 않은 서비스 목록은 기본 zone을 대상으로 하므로 실제 인터페이스·source에 적용되는 활성 zone과 다를 수 있습니다.
필터링된 iptables 출력은 체인 기본 정책·규칙 순서·jump 대상·다른 테이블·IPv6를 포함한 전체 ruleset을 보여주지 않습니다. 사용 중인 backend와 유효 runtime 정책을 확인하고 permanent 설정과의 차이도 검토하기 전에는 판정을 보류합니다.

# Apache 리스닝 포트 확인
sudo ss -tlnp | grep -E ":80 |:443 "
# 사례 출력에서 443만 관찰됨; 필요한 80 리스너/도달성은 별도 확인

# Listen 설정 확인
grep -r "Listen" /etc/httpd/conf/ /etc/httpd/conf.d/ | grep -v "#"
# /etc/httpd/conf.d/ssl.conf: Listen 443 https ← 443만 있음
# httpd.conf의 Listen 80이 주석 처리됨

80 포트의 리스너가 없다는 관찰은 이 사례의 단서이며, WAF 사용 여부만으로 그 원인이나 필요한 포트를 단정할 수 없습니다.
직접 HTTPS에 80 포트가 항상 필요한 것은 아니지만 HTTP 서비스나 HTTP-01 검증 경로에는 80 도달성 검토가 필요합니다. 아래 변경 예제는 일괄 실행하지 말고 기존 서비스와 origin 보호 경계에 대한 별도 검토 후에만 적용 여부를 결정해야 합니다.

sudo sed -i 's/^#Listen 80$/Listen 80/' /etc/httpd/conf/httpd.conf
sudo apachectl configtest && sudo systemctl restart httpd

# 확인
sudo ss -tlnp | grep ":80 "
# LISTEN 0 511 *:80 *:* ← 리스너 관찰 예시; 종단 간 정상 판정 아님