사이트맵

홈 현재 IPv4/IPv6 연결, ISP, 대략적인 위치 확인으로 시작합니다. 열기 인터넷 진단 도구 모음 DNS, 이메일, 개인정보 보호, 웹마스터, 개발자, 네트워크 문제별로 ipnawa 도구를 묶었습니다. 열기 네트워크 개념 허브 DNS, 이메일 인증, DNSSEC, SSL, 개인정보 보호 개념을 짧고 명확하게 정리한 학습 허브입니다. 열기

IP 주소 추적 IP 주소의 국가, 도시, ISP, ASN 정보를 조회합니다. 열기 브라우저 정보 브라우저 이름, 버전, 언어, User-Agent 정보를 확인합니다. 열기 User-Agent 확인 현재 브라우저의 User-Agent 문자열을 확인하고 브라우저, 렌더링 엔진, 운영체제, 디바이스 타입, Client Hints를 한 화면에서 파싱합니다. 열기 운영체제 정보 운영체제 플랫폼과 아키텍처 신호를 확인합니다. 열기 화면 정보 해상도, 가용 화면, 픽셀 비율, 색 심도를 확인합니다. 열기 디바이스 정보 기기 유형, 터치 지원, 방향, 네트워크 상태를 확인합니다. 열기 하드웨어 정보 CPU 코어, 메모리 등 하드웨어 신호를 확인합니다. 열기 시간 및 시간대 로컬 시간, 시간대, UTC 오프셋, 로케일을 확인합니다. 열기 위치 정보 위치 권한 상태와 좌표 정확도를 확인합니다. 열기 쿠키 정보 쿠키/로컬스토리지/세션스토리지 사용 가능 여부를 확인합니다. 열기 자바스크립트 정보 자바스크립트 런타임 및 관련 기능 지원을 점검합니다. 열기 이전 페이지 정보 유입 URL과 접속 경로를 확인합니다. 열기 디지털 지문 Canvas/WebGL 등 브라우저 지문 신호를 확인합니다. 열기 WebRTC 유출 테스트 WebRTC를 통한 네트워크 주소 노출 가능성을 점검합니다. 열기 핑 테스트 주요 엔드포인트와 사용자 입력 호스트의 지연 시간을 측정합니다. 열기 SEO 분석기 제목, 설명, 구조 등 핵심 SEO 요소를 분석합니다. 열기 DNS 누출 테스트 DNS 요청이 예상 경로 밖으로 누출되는지 확인합니다. 열기 개인정보 노출 점수 IP, IPv6, WebRTC, DNS, 브라우저 지문, 쿠키·스토리지 신호를 한 번에 점수화해 웹사이트가 볼 수 있는 개인정보 노출 범위를 확인합니다. 열기 IP 블랙리스트 체크 IP가 주요 DNSBL 블랙리스트에 등록되었는지 검사합니다. 열기 포트 검사 대상 TCP 포트의 열림/닫힘/필터 상태를 검사합니다. 열기 WHOIS / DNS 조회 도메인 WHOIS 및 핵심 DNS 레코드를 조회합니다. 열기 SSL 인증서 확인 SSL 인증서 발급자, 유효기간, 체인 상태를 확인합니다. 열기 서브넷 계산기 CIDR 기반 네트워크 범위와 호스트 수를 계산합니다. 열기 IP 변환기 IP 주소를 2진수/16진수/정수 형식으로 변환합니다. 열기 HTTP 헤더 확인 HTTP 응답 헤더, 상태코드, 응답시간을 조회합니다. 열기 리다이렉트 검사 리다이렉트 경로와 최종 URL을 추적합니다. 열기 robots.txt 검사 robots.txt 규칙과 Sitemap 지시문을 분석합니다. 열기 JSON 포매터 / 검증기 JSON 포맷팅/검증/미니파이를 브라우저에서 수행합니다. 열기 Base64 인코드/디코드 텍스트 Base64 인코드/디코드를 빠르게 수행합니다. 열기 URL 인코드/디코드 URL 컴포넌트 인코드/디코드를 수행합니다. 열기 이메일 헤더 분석기 이메일 헤더를 분석해 경로/인증 단서를 확인합니다. 열기 MAC 제조사 조회 MAC OUI 접두어로 제조사 정보를 조회합니다. 열기 JWT 디코더 JWT 헤더/페이로드와 만료시간을 점검합니다. 열기 정규표현식 테스트 정규표현식을 샘플 텍스트로 실시간 테스트합니다. 열기 텍스트 비교 두 텍스트의 차이점을 비교합니다. 열기 타임스탬프 변환기 Unix 타임스탬프와 날짜/시간을 상호 변환합니다. 열기 해시 생성기 SHA-256/SHA-1/MD5 등 해시를 생성합니다. 열기 보안 헤더 검사 HTTP 보안 헤더 적용 상태를 점검합니다. 열기 MX 레코드 조회 (메일 라우팅) MX 우선순위, 메일 서버 호스트, TTL을 확인해 메일 수신 라우팅 문제를 진단합니다. 열기 SPF 레코드 검사 (발신 정책) SPF TXT 정책을 파싱해 허용 발신 서버, include 체인, fail/softfail 동작을 점검합니다. 열기 DMARC 정책 검사 (도메인 보호) DMARC 태그(p, rua, ruf, adkim, aspf)를 분석해 도메인 스푸핑 방어 정책을 검증합니다. 열기 DKIM 레코드 검사 (전자서명) selector+domain 기반 DKIM TXT/CNAME 레코드를 조회해 서명 검증 실패 원인을 진단합니다. 열기 역방향 DNS 조회 IP 주소의 PTR(역방향 DNS) 레코드를 조회합니다. 열기 ASN 조회 IP의 ASN 소유자 및 네트워크 범위를 조회합니다. 열기 이메일 발송 종합 진단 도메인을 입력하면 MX, SPF, DMARC, DKIM 레코드를 한 번에 검사해 이메일 발송 가능성을 진단합니다. 열기 VPN 개인정보 보호 검사 WebRTC 누출, DNS 누출, IP 정보를 종합해 VPN이 실제로 개인정보를 보호하는지 확인합니다. 열기 Open Graph 미리보기 URL을 입력하면 카카오톡, 트위터, 페이스북 공유 시 실제로 어떻게 보이는지 미리 확인합니다. 열기 cURL 명령어 생성기 URL, 헤더, 메서드, 바디를 입력하면 실행 가능한 cURL 명령어를 자동으로 생성합니다. 열기 비밀번호 유출 확인 비밀번호를 서버에 전송하지 않고, k-익명성 방식으로 유출된 데이터베이스와 대조해 안전 여부를 즉시 확인합니다. 열기 비밀번호 생성기 길이, 대소문자, 숫자, 기호를 조합해 강력한 랜덤 비밀번호를 생성하고 클립보드에 복사합니다. 열기 DNS 건강도 검사 도메인의 A/AAAA, NS, MX, SPF, DMARC, CAA 구성을 점수로 진단해 DNS 운영 상태를 빠르게 점검합니다. 열기 DNS 전파 확인 여러 공개 리졸버의 DNS 응답을 비교해 A, AAAA, MX, TXT 같은 레코드가 전 세계에서 같은 값으로 전파됐는지 확인합니다. 열기 DNS 레코드 조회 A, AAAA, CNAME, MX, NS, TXT, CAA, SOA 레코드를 한 번에 조회해 현재 공개 DNS 구성을 빠르게 스냅샷으로 확인합니다. 열기 DNSSEC 검사 도메인의 DNSKEY, DS 레코드와 체인 오브 트러스트 구성을 확인하고 DNSSEC 검증 신호를 점검합니다. 열기

DNS와 도메인 도구 모음 DNS와 도메인 문제를 확인할 때 바로 사용할 수 있는 무료 진단 도구와 관련 가이드를 한곳에 모았습니다. 열기 이메일 도착률 도구 모음 이메일 도착률 문제를 확인할 때 바로 사용할 수 있는 무료 진단 도구와 관련 가이드를 한곳에 모았습니다. 열기 VPN과 개인정보 보호 도구 모음 VPN과 개인정보 보호 문제를 확인할 때 바로 사용할 수 있는 무료 진단 도구와 관련 가이드를 한곳에 모았습니다. 열기 웹마스터와 SEO 도구 모음 웹마스터와 SEO 문제를 확인할 때 바로 사용할 수 있는 무료 진단 도구와 관련 가이드를 한곳에 모았습니다. 열기 개발자 유틸리티 도구 모음 개발자 유틸리티 문제를 확인할 때 바로 사용할 수 있는 무료 진단 도구와 관련 가이드를 한곳에 모았습니다. 열기 네트워크 연결 도구 모음 네트워크 연결 문제를 확인할 때 바로 사용할 수 있는 무료 진단 도구와 관련 가이드를 한곳에 모았습니다. 열기

ipnawa 소개 ipnawa.com이 제공하는 IP, DNS, 이메일, 보안, SEO 진단 도구와 Academy 콘텐츠의 운영 목적, 작성 기준, 정정 문의 경로를 확인하세요. 열기 개인정보 및 쿠키 안내 ipnawa.com의 IP 진단, 브라우저 정보 확인, 광고/쿠키 사용 및 문의 처리 시 데이터 처리 기준을 확인하세요. 열기 이용약관 ipnawa.com 진단 도구와 Academy 콘텐츠 이용 조건, 책임 제한, 금지 행위, 광고 및 외부 조회 관련 안내입니다. 열기 문의 및 운영자 정보 ipnawa.com 운영, 광고, 개인정보, 오류 정정, 콘텐츠 개선 요청을 보낼 수 있는 공식 문의 안내입니다. 열기

XML sitemap 모든 색인 가능 도구, Academy, 카테고리, 정책 페이지 URL입니다. 열기 현재 언어 XML sitemap 이 언어판의 색인 가능 URL만 모은 XML 사이트맵입니다. 열기 Academy Atom feed 모든 지원 언어의 Academy 글 업데이트 피드입니다. 열기 LLMs documentation AI 답변과 인용을 위한 ipnawa 도구, Academy, 구조화 데이터 요약입니다. 열기 ads.txt 광고 크롤러가 확인하는 판매자 승인 파일입니다. 열기

DNS 기본과 레코드 종류 DNS는 도메인을 실제 서비스 위치로 연결하는 전화번호부 역할을 합니다. A, AAAA, CNAME, MX, TXT가 각각 무엇을 뜻하는지 이해하면 WHOIS, DNS 건강도, 메일 진단 결과를 훨씬 빠르게 읽을 수 있습니다. 열기 이메일 인증: SPF, DKIM, DMARC SPF는 누가 보낼 수 있는지, DKIM은 내용이 바뀌지 않았는지, DMARC는 실패 시 어떻게 처리할지를 정의합니다. 세 가지가 함께 맞물려야 스팸 판정과 발신 실패를 줄일 수 있습니다. 열기 DNSSEC와 체인 오브 트러스트 DNSSEC는 DNS 응답이 위변조되지 않았다는 신뢰 사슬을 만드는 기술입니다. DNSKEY만 있고 DS가 없거나, 상위 존 연결이 끊기면 검증이 실패할 수 있어 registrar와 DNS 제공업체 설정을 함께 봐야 합니다. 열기 SSL/TLS와 인증서 만료 이해하기 인증서 브랜드보다 중요한 것은 어떤 호스트 이름으로 접속했는지, 체인이 완전한지, 만료일이 실제 응답 기준으로 무엇인지입니다. HTTPS 진단은 인증서만 보지 말고 리다이렉트, 보안 헤더, 실제 최종 호스트까지 함께 확인해야 합니다. 열기 VPN, DNS 누출, WebRTC 누출 VPN을 켰다고 해서 모든 정보가 자동으로 가려지지는 않습니다. DNS 요청, WebRTC 후보 IP, 브라우저 지문은 별도로 노출될 수 있어서 실제 프라이버시 상태는 IP 확인만으로 판단하면 부족합니다. 열기 DNS 전파와 TTL 이해하기 DNS를 바꾼 뒤 결과가 즉시 같아지지 않는 이유는 권한 네임서버, 재귀 캐시, TTL 만료 시점이 서로 다른 속도로 반영되기 때문입니다. 열기 메일 라우팅과 MX 우선순위 이메일은 MX 우선순위, 대체 서버, 실제 연결 가능 여부를 따라 전달됩니다. 이 흐름을 이해하면 특정 도메인만 수신 실패하는 이유를 더 빨리 찾을 수 있습니다. 열기 보안 헤더가 실제로 막아주는 것 HSTS, CSP, X-Frame-Options, Referrer-Policy, Permissions-Policy는 각각 다른 웹 공격면을 줄이는 브라우저 정책 신호입니다. 열기 리다이렉트와 캐노니컬 정리 301/302 체인과 canonical 신호는 브라우저와 검색엔진에 어떤 URL이 기준인지 알려줍니다. 프로토콜·호스트가 섞이면 SEO와 캐시 일관성이 흔들릴 수 있습니다. 열기 브라우저 지문과 추적 신호 User-Agent, 화면 크기, 언어, 시간대, 폰트, GPU, 캔버스 정보가 조합되면 쿠키 없이도 사용자를 꽤 고유하게 식별할 수 있습니다. 열기 DMARC 정책과 정렬 이해하기 DMARC는 단순히 레코드가 있느냐보다 SPF/DKIM 정렬과 p=none, quarantine, reject 정책 강도가 실제 수신 처리에 어떤 영향을 주는지가 더 중요합니다. 열기 SSL 체인과 중간 인증서 브라우저가 인증서를 신뢰하려면 leaf 인증서만이 아니라 중간 인증서와 루트 체인 연결이 완전해야 합니다. 체인이 빠지면 일부 기기에서만 오류가 날 수 있습니다. 열기 robots.txt와 크롤러 동작 robots.txt는 색인 삭제 도구가 아니라 크롤링 경로를 안내하는 규칙입니다. 차단과 canonical, noindex의 역할이 서로 다르기 때문에 같이 이해해야 합니다. 열기 ASN과 네트워크 라우팅 기초 ASN은 어떤 사업자나 조직이 특정 IP 대역을 광고하고 제어하는지 보여줍니다. ISP, 클라우드, 트래픽 경로를 이해할 때 핵심 기준이 됩니다. 열기 Reverse DNS와 PTR 레코드 Reverse DNS는 IP가 어떤 호스트명으로 역해석되는지 보여줍니다. 메일 서버 신뢰도, 로그 분석, 서버 식별에서 PTR과 정방향 일치가 중요하게 작용합니다. 열기 DNS_PROBE_FINISHED_NXDOMAIN 오류 원인과 해결 순서 DNS_PROBE_FINISHED_NXDOMAIN은 브라우저가 도메인의 IP 주소를 찾지 못했다는 뜻입니다. 도메인 오타, 만료, 네임서버 변경, DNS 레코드 삭제, 전파 지연, 로컬 DNS 캐시 문제가 섞일 수 있어 DNS 레코드와 전파 상태를 함께 봐야 합니다. 열기 DNS_PROBE_FINISHED_BAD_CONFIG 원인과 해결 순서 DNS_PROBE_FINISHED_BAD_CONFIG는 브라우저가 사용하는 DNS 설정이 잘못됐거나 응답을 안정적으로 처리하지 못할 때 나타납니다. 공유기 DNS, OS DNS, 브라우저 Secure DNS, VPN, 사내 DNS, DNS 캐시를 순서대로 분리해야 합니다. 열기 DNS 서버가 응답하지 않음 원인과 해결 순서 “DNS 서버가 응답하지 않음”은 브라우저나 운영체제가 도메인 이름을 IP 주소로 바꾸는 과정에서 리졸버 응답을 받지 못할 때 나타납니다. 공유기 DNS, ISP DNS 장애, VPN, 보안 DNS, 도메인 레코드 문제를 분리해야 합니다. 열기 DNS_PROBE_FINISHED_NO_INTERNET 원인과 해결 순서 DNS_PROBE_FINISHED_NO_INTERNET은 브라우저가 DNS 조회나 인터넷 경로를 사용할 수 없다고 판단할 때 나타납니다. 실제 인터넷 끊김, DNS 서버 응답 없음, VPN 킬스위치, 프록시, 공유기, ISP 장애를 분리해야 합니다. 열기 와이파이 연결됨 인터넷 안됨 원인과 해결 순서 “와이파이는 연결됐는데 인터넷이 안 됨”은 무선 연결 자체와 인터넷 경로가 서로 다른 문제라는 뜻입니다. 공유기, DNS, ISP 장애, 공용 와이파이 로그인, VPN, IPv6, 기기 캐시를 분리해야 합니다. 열기 공용 와이파이 로그인 화면 안 뜸 원인과 해결 순서 공용 와이파이 로그인 화면이 안 뜨면 기기는 네트워크에 붙었지만 인터넷 사용 허가가 끝나지 않은 상태일 수 있습니다. HTTPS 리다이렉트 차단, DNS, 브라우저 캐시, VPN, 프록시, 쿠키, Captive Portal 감지를 확인해야 합니다. 열기 VPN 연결됨 인터넷 안됨 원인과 해결 순서 VPN은 연결됐는데 인터넷이 안 되는 문제는 터널 연결과 실제 외부 경로가 따로 깨졌을 때 나타납니다. 킬스위치, DNS, split tunneling, IPv6, 프록시, VPN 서버 장애, 회사망 정책을 분리해야 합니다. 열기 모바일 데이터 안됨 원인과 해결 순서 모바일 데이터가 안 되는 문제는 통신사 신호, 요금제 제한, APN, DNS, IPv6, VPN, 테더링, 브라우저 캐시가 섞일 수 있습니다. 와이파이 문제와 분리하고 현재 IP, DNS, 경로를 함께 봐야 합니다. 열기 ERR_NAME_NOT_RESOLVED 오류 원인과 해결 순서 ERR_NAME_NOT_RESOLVED는 브라우저가 입력한 호스트 이름을 IP 주소로 해석하지 못할 때 나타납니다. 도메인 오타, DNS 레코드 누락, 네임서버 전파 지연, 사내 DNS, VPN DNS, 브라우저 캐시를 순서대로 분리해야 합니다. 열기 서버 IP 주소를 찾을 수 없음 원인과 해결 순서 “서버 IP 주소를 찾을 수 없음”은 브라우저가 입력한 도메인을 IP 주소로 해석하지 못했다는 뜻입니다. 도메인 오타, www 누락, DNS 레코드 삭제, 네임서버 전파, 도메인 만료, 로컬 DNS 캐시를 함께 봐야 합니다. 열기 ERR_CONNECTION_TIMED_OUT 원인과 해결 순서 ERR_CONNECTION_TIMED_OUT은 브라우저가 서버에 연결 요청을 보냈지만 정해진 시간 안에 응답을 받지 못했다는 뜻입니다. 서버 다운, 방화벽, 포트 차단, DNS 지연, 라우팅 문제, CDN 또는 호스팅 장애를 순서대로 분리해야 합니다. 열기 ERR_CONNECTION_REFUSED 원인과 해결 순서 ERR_CONNECTION_REFUSED는 대상 IP까지는 도달했지만 해당 포트에서 연결을 받아들이지 않을 때 자주 나타납니다. 서버 프로세스 중지, 잘못된 포트, 방화벽 거부, 로컬 개발 서버 미실행, 프록시 또는 CDN 원본 설정을 분리해서 확인해야 합니다. 열기 ERR_NETWORK_CHANGED 원인과 해결 순서 ERR_NETWORK_CHANGED는 페이지를 불러오는 중 브라우저가 쓰던 네트워크 경로가 바뀌었을 때 나타납니다. Wi-Fi 전환, VPN 연결/해제, 프록시, IPv4/IPv6 경로 변화, DNS 리졸버 변경, 공유기 불안정을 함께 확인해야 합니다. 열기 ERR_INTERNET_DISCONNECTED 원인과 해결 순서 ERR_INTERNET_DISCONNECTED는 브라우저가 인터넷으로 나갈 수 있는 연결을 찾지 못할 때 나타납니다. 기기 네트워크, 공유기, ISP, VPN, 프록시, DNS 문제를 구분해야 실제 사이트 장애인지 로컬 연결 문제인지 알 수 있습니다. 열기 ERR_ADDRESS_UNREACHABLE 원인과 해결 순서 ERR_ADDRESS_UNREACHABLE은 브라우저가 대상 IP나 네트워크 경로로 도달할 수 없을 때 나타납니다. 로컬 라우팅, 잘못된 IP, VPN/프록시, 공유기, CGNAT, IPv6 경로, 방화벽을 순서대로 분리해야 합니다. 열기 Chrome “사이트에 연결할 수 없음” 원인과 해결 순서 Chrome의 “사이트에 연결할 수 없음” 화면은 하나의 원인이 아니라 DNS 해석 실패, 연결 시간 초과, 포트 거부, 서버 다운, 프록시/VPN, SSL 문제를 묶어 보여주는 넓은 증상입니다. 화면 아래 오류 코드를 기준으로 순서를 정해야 합니다. 열기 ERR_HTTP2_PROTOCOL_ERROR 원인과 해결 순서 ERR_HTTP2_PROTOCOL_ERROR는 브라우저와 서버 또는 CDN 사이의 HTTP/2 연결 처리 중 프로토콜 오류가 발생했다는 뜻입니다. 압축 헤더, CDN/프록시, TLS, 서버 push, gRPC, WAF, 브라우저 캐시, 최근 배포를 함께 확인해야 합니다. 열기 ERR_CACHE_MISS 원인과 해결 순서 ERR_CACHE_MISS는 Chrome이 캐시된 데이터나 다시 제출해야 하는 요청을 처리하지 못할 때 나타나는 오류입니다. 뒤로가기 후 POST 재전송, 폼 제출, 캐시 정책, 리다이렉트, 서비스워커, 브라우저 확장을 구분해야 합니다. 열기 ERR_BLOCKED_BY_CLIENT 원인과 해결 순서 ERR_BLOCKED_BY_CLIENT는 서버가 아니라 브라우저 확장, 콘텐츠 차단기, 보안 프로그램, 개인정보 보호 설정이 특정 요청을 막을 때 나타납니다. 이미지, 스크립트, 분석 파일, CDN 경로, 파일명 패턴을 분리해야 합니다. 열기 PR_CONNECT_RESET_ERROR 원인과 해결 순서 PR_CONNECT_RESET_ERROR는 Firefox에서 HTTPS 연결이 중간에 재설정될 때 나타나는 오류입니다. TLS, 프록시, VPN, 보안 프로그램의 HTTPS 검사, 서버 reset, CDN 원본 연결, 방화벽을 함께 확인해야 합니다. 열기 PR_END_OF_FILE_ERROR 원인과 Firefox 해결 순서 PR_END_OF_FILE_ERROR는 Firefox가 TLS 연결을 완료하기 전에 연결 끝을 만나거나 협상에 실패했을 때 보이는 오류입니다. 인증서만의 문제가 아니라 TLS 버전, cipher suite, 보안 프로그램의 HTTPS 검사, 프록시, VPN, CDN/원본 설정을 함께 봐야 합니다. 열기 SEC_ERROR_UNKNOWN_ISSUER 원인과 해결 순서 SEC_ERROR_UNKNOWN_ISSUER는 Firefox가 인증서를 발급한 기관을 신뢰하지 못할 때 나타납니다. 자체 서명 인증서, 누락된 중간 인증서, 회사 프록시나 백신의 HTTPS 검사, CDN과 원본 체인 불일치, 잘못된 루트 인증서 저장소를 분리해야 합니다. 열기 SSL_ERROR_NO_CYPHER_OVERLAP 원인과 해결 순서 SSL_ERROR_NO_CYPHER_OVERLAP은 Firefox와 서버가 공통으로 사용할 수 있는 TLS 암호화 방식이나 프로토콜을 찾지 못했을 때 발생합니다. 너무 오래된 TLS만 허용하거나, 너무 좁은 cipher suite, CDN/원본 정책 불일치, 보안 장비의 TLS 검사 문제가 원인이 될 수 있습니다. 열기 MOZILLA_PKIX_ERROR_MITM_DETECTED 원인과 해결 순서 MOZILLA_PKIX_ERROR_MITM_DETECTED는 Firefox가 HTTPS 연결 중간에서 인증서가 가로채이거나 바뀐 것으로 판단할 때 나타납니다. 회사 프록시, 백신 HTTPS 검사, 악성 프록시, VPN, 로컬 루트 인증서, 공용 와이파이 보안 장비를 구분해야 합니다. 열기 ERR_CONNECTION_ABORTED 원인과 해결 순서 ERR_CONNECTION_ABORTED는 브라우저가 연결을 시작했지만 중간에서 연결이 끊기거나 취소됐을 때 나타납니다. 서버 reset, 프록시/VPN, 방화벽, CDN 원본 연결, 큰 응답 중단, 브라우저 확장, 네트워크 변경을 순서대로 분리해야 합니다. 열기 ERR_CONNECTION_FAILED 원인과 해결 순서 ERR_CONNECTION_FAILED는 Chrome이 대상 서버와 연결을 만들지 못했을 때 나타나는 넓은 오류입니다. DNS, 포트, 방화벽, 프록시, VPN, SSL, CDN, 서버 다운 중 어디에서 실패하는지 좁히는 것이 핵심입니다. 열기 ERR_PROXY_CONNECTION_FAILED 원인과 해결 순서 ERR_PROXY_CONNECTION_FAILED는 브라우저가 설정된 프록시 서버를 통해 대상 사이트에 연결하지 못할 때 나타납니다. 잘못된 프록시 주소, PAC 파일, 인증 실패, VPN 정책, 회사 보안 장비, DNS와 HTTPS 터널 문제를 분리해야 합니다. 열기 ERR_QUIC_PROTOCOL_ERROR 원인과 해결 순서 ERR_QUIC_PROTOCOL_ERROR는 Chrome이 QUIC 또는 HTTP/3 연결을 처리하는 중 오류를 만났을 때 나타납니다. UDP 443 차단, CDN HTTP/3 설정, TLS, 프록시/VPN, 방화벽, 브라우저 캐시와 확장을 함께 확인해야 합니다. 열기 ERR_EMPTY_RESPONSE 원인과 해결 순서 ERR_EMPTY_RESPONSE는 브라우저가 서버에 연결했지만 응답 본문이나 HTTP 응답을 제대로 받지 못했을 때 나타납니다. 서버 프로세스 중단, 프록시/CDN 연결 끊김, 방화벽, 리다이렉트 충돌, 압축 또는 헤더 오류를 함께 확인해야 합니다. 열기 ERR_CONNECTION_RESET 원인과 해결 순서 ERR_CONNECTION_RESET은 연결이 만들어진 뒤 중간에서 TCP 연결이 강제로 끊겼다는 뜻입니다. 서버 재시작, 방화벽 reset, 프록시/CDN timeout, VPN 경로 불안정, MTU 문제, HTTP/2 또는 TLS 설정 충돌이 원인이 될 수 있습니다. 열기 ERR_CONNECTION_CLOSED 원인과 해결 순서 ERR_CONNECTION_CLOSED는 브라우저와 서버 사이의 연결이 응답을 끝내기 전에 닫혔을 때 나타납니다. 서버 앱 종료, 리버스 프록시 연결 종료, CDN 원본 문제, TLS/HTTP2 충돌, 보안 장비가 원인이 될 수 있습니다. 열기 ERR_TUNNEL_CONNECTION_FAILED 원인과 해결 순서 ERR_TUNNEL_CONNECTION_FAILED는 브라우저가 프록시나 VPN 터널을 통해 HTTPS 연결을 만들지 못할 때 나타납니다. 잘못된 프록시 주소, 인증 실패, 회사망 차단, VPN 분할 터널링, DNS와 인증서 검사 장비를 함께 확인해야 합니다. 열기 HTTP 403 Forbidden 원인과 해결 순서 HTTP 403 Forbidden은 서버가 요청을 이해했지만 접근을 허용하지 않는다는 뜻입니다. 로그인 권한, IP 차단, 방화벽/WAF, robots 정책, 파일 권한, 보안 헤더, CDN 규칙이 섞일 수 있어 응답 헤더와 접근 조건을 함께 봐야 합니다. 열기 HTTP 404 Not Found 원인과 해결 순서 HTTP 404 Not Found는 요청한 URL에 해당하는 리소스를 서버가 찾지 못한다는 뜻입니다. 삭제된 페이지, 잘못된 링크, 슬래시/대소문자 차이, 리다이렉트 누락, 라우팅 오류, sitemap의 오래된 URL이 검색 유입 손실로 이어질 수 있습니다. 열기 HTTP 500 Internal Server Error 원인과 해결 순서 HTTP 500 Internal Server Error는 서버 내부에서 요청을 처리하다 실패했다는 뜻입니다. 애플리케이션 예외, PHP/서버 설정 오류, DB 연결 실패, 권한 문제, 플러그인 충돌, 프록시 업스트림 실패가 같은 화면으로 보일 수 있습니다. 열기 HTTP 502 Bad Gateway 원인과 해결 순서 HTTP 502 Bad Gateway는 게이트웨이, 프록시, CDN이 원본 서버나 업스트림에서 올바른 응답을 받지 못했을 때 나타납니다. CDN 엣지, 리버스 프록시, 로드밸런서, 원본 서버, DNS, SSL 모드, 업스트림 포트를 함께 분리해야 합니다. 열기 HTTP 503 Service Unavailable 원인과 해결 순서 HTTP 503 Service Unavailable은 서버가 일시적으로 요청을 처리할 수 없을 때 나타납니다. 점검 모드, 과부하, worker 부족, rate limit, autoscaling 지연, 원본 서버 다운, CDN 보호 모드가 원인일 수 있습니다. 열기 HTTP 504 Gateway Timeout 원인과 해결 순서 HTTP 504 Gateway Timeout은 게이트웨이, 프록시, CDN, 로드밸런서가 원본 서버나 업스트림 응답을 제한 시간 안에 받지 못했을 때 나타납니다. 원본 서버 지연, DB 쿼리, 업스트림 API, 네트워크 경로, timeout 설정을 함께 봐야 합니다. 열기 Cloudflare 520 Web Server Returned an Unknown Error 원인과 해결 순서 Cloudflare 520은 Cloudflare가 원본 서버에서 표준 HTTP 오류로 분류하기 어려운 응답을 받았을 때 나타납니다. 빈 응답, 비정상 헤더, 원본 앱 예외, WAF, 압축, HTTP/2, 쿠키나 큰 헤더 문제를 함께 확인해야 합니다. 열기 Cloudflare 521 Web Server Is Down 원인과 해결 순서 Cloudflare 521은 Cloudflare가 원본 서버에 연결하려 했지만 원본이 연결을 거부하거나 응답하지 않을 때 나타납니다. 원본 웹서버 중지, 80/443 포트 미수신, 방화벽, 보안그룹, Cloudflare IP 차단을 먼저 봐야 합니다. 열기 Cloudflare 522 Connection Timed Out 원인과 해결 순서 Cloudflare 522는 Cloudflare가 원본 서버와 TCP 연결을 만들거나 유지하지 못해 시간이 초과됐을 때 나타납니다. 원본 서버 과부하, 네트워크 경로 지연, 방화벽 drop, 라우팅 문제, 포트 응답 지연을 확인해야 합니다. 열기 Cloudflare 523 Origin Is Unreachable 원인과 해결 순서 Cloudflare 523은 Cloudflare가 원본 서버의 IP에는 접근하려 하지만 네트워크 경로상 원본에 도달하지 못할 때 나타납니다. 원본 IP 변경, 라우팅 장애, 방화벽, 클라우드 보안그룹, BGP/ASN 경로 문제를 함께 확인해야 합니다. 열기 Cloudflare 524 A Timeout Occurred 원인과 해결 순서 Cloudflare 524는 Cloudflare와 원본 서버 사이의 연결은 만들어졌지만 원본이 제한 시간 안에 HTTP 응답을 끝내지 못했을 때 나타납니다. 느린 DB 쿼리, 외부 API, 긴 작업, worker 부족, 캐시 미스, timeout 설정을 확인해야 합니다. 열기 Cloudflare 526 Invalid SSL Certificate 원인과 해결 순서 Cloudflare 526은 Cloudflare가 원본 서버 인증서를 신뢰할 수 없다고 판단할 때 나타납니다. Full strict 모드에서 만료, 자체 서명, 이름 불일치, 중간 인증서 누락, CAA/DNS 변경, 원본 SNI 설정을 확인해야 합니다. 열기 Cloudflare 1016 Origin DNS Error 원인과 해결 순서 Cloudflare 1016은 Cloudflare가 원본 호스트명을 DNS로 해석하지 못할 때 나타납니다. A/AAAA 레코드 누락, CNAME 대상 삭제, 잘못된 원본 호스트명, 내부 전용 DNS, DNSSEC/네임서버 문제를 먼저 봐야 합니다. 열기 Cloudflare 1020 Access Denied 원인과 해결 순서 Cloudflare 1020은 Cloudflare 방화벽, WAF, 보안 규칙, Bot Fight Mode, 국가/ASN/IP 차단 규칙이 요청을 거부할 때 나타납니다. 원본 서버 장애보다 접근 정책과 요청 신호를 먼저 확인해야 합니다. 열기 IPv4와 IPv6 현재 연결 구분하기 IPv4와 IPv6가 둘 다 감지되어도 이번 웹 요청이 어느 프로토콜로 나갔는지는 별도 문제입니다. 현재 연결 배지를 기준으로 실제 접속 경로를 읽어야 VPN, 통신사망, DNS, 서버 IPv6 준비 상태를 정확히 판단할 수 있습니다. 열기 공인 IP와 사설 IP 차이 이해하기 공인 IP는 인터넷에서 보이는 주소이고 사설 IP는 공유기나 내부망 안에서 쓰는 주소입니다. 내 기기 IP와 웹사이트가 보는 IP가 다른 이유를 알면 VPN, 회사망, 공유기, 포트포워딩 문제를 더 빠르게 분리할 수 있습니다. 열기 CGNAT 환경에서 포트포워딩이 안 되는 이유 CGNAT는 통신사가 여러 가입자에게 하나의 공인 IPv4를 공유시키는 구조입니다. 공유기에서 포트포워딩을 맞게 설정해도 통신사 NAT 바깥에서 들어오는 연결이 막힐 수 있어 공인 IP 유형을 먼저 확인해야 합니다. 열기 Double NAT 때문에 포트포워딩이 안 되는 이유 Double NAT는 통신사 모뎀, 공유기, 메시 라우터, VPN 장비가 각각 NAT를 적용해 외부 연결이 여러 단계에서 막히는 상태입니다. 포트포워딩을 한 공유기만 확인하면 실제 차단 지점을 놓치기 쉽습니다. 열기 공유기 WAN IP가 사설 IP일 때 의미 공유기 WAN IP가 10.x.x.x, 172.16-31.x.x, 192.168.x.x 또는 100.64.0.0/10 대역이면 공유기 앞쪽에 또 다른 NAT가 있을 수 있습니다. 이 경우 공인 IP처럼 보이는 외부 주소와 공유기 WAN 주소가 달라집니다. 열기 NAT Type Strict가 뜨는 이유와 확인 순서 게임 콘솔이나 PC 게임에서 NAT Type Strict가 뜨면 매치메이킹, 음성 채팅, P2P 연결이 불안정해질 수 있습니다. 원인은 포트 차단, Double NAT, CGNAT, 방화벽, UPnP 충돌, VPN 경로가 섞여 있을 때가 많습니다. 열기 DDNS가 현재 공인 IP로 갱신되지 않는 이유 DDNS는 변하는 공인 IP를 도메인에 연결하지만, 공유기 WAN IP와 실제 외부 공인 IP가 다르거나 업데이트 클라이언트가 잘못된 IP를 보내면 도메인이 오래된 주소를 가리킬 수 있습니다. 열기 핑이 높고 지터가 심할 때 확인 순서 핑이 높거나 지터가 크면 게임, 영상통화, 원격근무, 실시간 서비스가 끊기는 것처럼 느껴질 수 있습니다. 단순히 속도만 보지 말고 지연 시간, 변동 폭, 패킷 손실, Wi-Fi 품질, VPN, 라우팅 경로를 함께 분리해야 합니다. 열기 패킷 손실 원인과 확인 순서 패킷 손실은 일부 네트워크 요청이 목적지에 도착하지 않거나 응답이 돌아오지 않는 상태입니다. 게임 끊김, 화상회의 음성 깨짐, 업로드 실패, 간헐적 타임아웃은 속도보다 손실과 재전송 문제가 핵심일 수 있습니다. 열기 traceroute 별표(*)와 timeout 의미 traceroute에서 별표가 보인다고 해서 그 지점이 항상 장애라는 뜻은 아닙니다. 일부 라우터는 ICMP TTL 초과 응답을 제한하거나 낮은 우선순위로 처리하지만, 실제 웹 트래픽은 계속 전달될 수 있습니다. 열기 IPv6가 IPv4보다 느리게 느껴질 때 IPv6가 항상 IPv4보다 빠르거나 느린 것은 아닙니다. ISP 라우팅, DNS AAAA 응답, CDN 엣지 선택, VPN 지원 여부, 방화벽, MTU 문제에 따라 같은 사이트도 IPv4와 IPv6 성능이 다를 수 있습니다. 열기 IPv6가 감지되지 않는 이유와 확인 순서 IPv6가 보이지 않는 이유는 회선 미지원, 공유기 설정, 운영체제 비활성화, DNS AAAA 응답 부족, VPN 우회 등 여러 원인이 섞일 수 있습니다. IPv4 연결 자체는 정상이어도 IPv6 준비 상태는 별도로 봐야 합니다. 열기 IP 위치가 실제 위치와 다르게 나오는 이유 IP 위치는 GPS가 아니라 통신사, VPN, 클라우드, 프록시, GeoIP 데이터베이스를 기반으로 한 추정값입니다. 도시나 국가가 다르게 보일 때는 IP 누출인지, 데이터베이스 지연인지, 브라우저 위치 권한 문제인지 분리해서 봐야 합니다. 열기 IP 주소가 자꾸 바뀌는 이유 공인 IP는 통신사 DHCP 임대, 공유기 재부팅, 모바일망 이동, VPN 서버 변경, IPv4/IPv6 우선순위 변화에 따라 달라질 수 있습니다. IP가 바뀌는 원인을 알면 로그인 보안 알림, 접속 제한, 포트포워딩 문제를 더 빨리 해석할 수 있습니다. 열기 DNS 누출 원인과 해결 순서 DNS 누출은 VPN을 켰는데도 도메인 조회가 ISP나 예상 밖 리졸버로 나가는 상황입니다. IP, DNS, WebRTC를 함께 비교해야 실제 프라이버시 노출면을 정확히 볼 수 있습니다. 열기 DNS over HTTPS가 VPN DNS 누출처럼 보일 때 DNS over HTTPS는 브라우저나 운영체제가 DNS 질의를 HTTPS로 보내는 방식입니다. VPN이 자체 DNS를 쓰도록 설계되어 있어도 브라우저 DoH가 별도 resolver를 사용하면 DNS 누출 테스트 결과가 예상과 다르게 보일 수 있습니다. 열기 VPN 사용 중 WebRTC IP 누출이 의심될 때 WebRTC는 브라우저의 실시간 통신 기능이며, 네트워크 후보 주소를 수집하는 과정에서 VPN 밖의 로컬 또는 공인 IP 단서가 보일 수 있습니다. VPN IP가 바뀌어도 WebRTC 후보와 DNS 결과는 별도로 확인해야 합니다. 열기 VPN을 켰는데 위치가 다르게 보이는 이유 VPN 위치와 IP 위치가 다르게 보이는 이유는 GeoIP 데이터베이스 지연, VPN 출구 서버 위치, DNS 리졸버 위치, 브라우저 위치 권한, 계정 위치 신호가 섞이기 때문입니다. IP 위치 하나만으로 누출을 단정하면 안 됩니다. 열기 VPN을 켰는데 IP가 바뀌지 않는 이유 VPN을 켰는데도 내 IP가 그대로 보이면 VPN 터널 미연결, 분할 터널링, 브라우저 WebRTC 노출, DNS 우회, IPv6 우회, 같은 국가 출구 서버 선택 같은 원인을 순서대로 분리해야 합니다. IP 하나만 다시 보지 말고 DNS와 WebRTC까지 함께 확인해야 실제 보호 상태가 보입니다. 열기 내 IP가 블랙리스트에 오른 이유와 해제 순서 IP 블랙리스트 등록은 스팸 발송, 감염된 기기, 공유 호스팅 평판, 역방향 DNS 부족, 갑작스러운 발송량 증가 때문에 생길 수 있습니다. 단순히 해제 요청만 보내기보다 발송 인증, rDNS, 서버 로그, 공유 IP 여부를 먼저 확인해야 재등록을 줄일 수 있습니다. 열기 이메일 도착률 기본 체크리스트 메일이 스팸함으로 가거나 아예 도착하지 않을 때는 MX, SPF, DKIM, DMARC를 같은 순서로 점검해야 합니다. 네 레코드가 맞아야 회원가입, 주문, 알림 메일의 수익 흐름이 막히지 않습니다. 열기 SSL 인증서 만료와 갱신 체크리스트 SSL 인증서 만료는 검색 노출, 광고 랜딩 심사, 로그인 보안, API 연결에 동시에 영향을 줄 수 있습니다. 자동 갱신을 믿더라도 실제 제공 인증서와 만료일을 정기적으로 확인해야 합니다. 열기 www와 비www SSL 인증서가 다를 때 해결 순서 www.example.com과 example.com은 같은 사이트처럼 보여도 TLS 인증서, 리다이렉트, canonical, HSTS가 다르게 동작할 수 있습니다. 한쪽만 정상이어도 다른 쪽 방문자는 인증서 오류나 검색 신호 분산을 겪을 수 있습니다. 열기 NET::ERR_CERT_COMMON_NAME_INVALID 오류 해결 순서 NET::ERR_CERT_COMMON_NAME_INVALID는 접속한 호스트명과 SSL 인증서에 적힌 이름이 맞지 않을 때 자주 발생합니다. www/비www, 서브도메인, CDN, 리다이렉트, 인증서 SAN을 함께 확인해야 사용자가 보는 최종 URL을 안전하게 고칠 수 있습니다. 열기 NET::ERR_CERT_DATE_INVALID 오류 해결 순서 NET::ERR_CERT_DATE_INVALID는 SSL 인증서가 만료됐거나 아직 유효하지 않거나, 기기 시간이 잘못됐을 때 나타납니다. 인증서 만료일, 서버가 실제 제공하는 인증서, CDN과 원본 인증서, 클라이언트 시간 설정을 분리해서 확인해야 합니다. 열기 NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM 오류 해결 순서 NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM은 인증서 서명 알고리즘이 너무 약하거나 오래된 체인을 브라우저가 신뢰하지 않을 때 나타납니다. 인증서 자체뿐 아니라 중간 인증서, CA 체인, TLS 정책, CDN과 원본 서버가 제공하는 실제 인증서를 함께 확인해야 합니다. 열기 NET::ERR_CERT_SYMANTEC_LEGACY 오류 해결 순서 NET::ERR_CERT_SYMANTEC_LEGACY는 Chrome이 더 이상 신뢰하지 않는 오래된 Symantec 계열 인증서나 레거시 체인을 감지했을 때 나타납니다. 새 인증서 발급, 중간 인증서 교체, CDN/원본 동시 배포가 필요합니다. 열기 NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED 오류 해결 순서 NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED는 Chrome이 인증서 투명성 로그 증거를 충분히 확인하지 못할 때 나타납니다. 잘못 발급된 인증서, CT 로그 누락, CDN 인증서 배포 문제, 오래된 중간 체인을 분리해야 합니다. 열기 NET::ERR_CERT_VALIDITY_TOO_LONG 오류 해결 순서 NET::ERR_CERT_VALIDITY_TOO_LONG은 인증서 유효 기간이 브라우저 정책보다 길다고 판단될 때 나타납니다. 오래 전에 발급된 장기 인증서, 사설 CA, 내부 인증서, CDN/원본 불일치를 확인하고 정책에 맞는 새 인증서로 교체해야 합니다. 열기 NET::ERR_CERT_INVALID 오류 원인과 해결 순서 NET::ERR_CERT_INVALID는 Chrome이 인증서를 유효하지 않다고 판단하는 넓은 오류입니다. 만료, 이름 불일치, 신뢰되지 않는 CA, 폐기, 약한 서명, CT 문제, 프록시 변조가 모두 원인이 될 수 있어 세부 증거를 순서대로 분리해야 합니다. 열기 ERR_BAD_SSL_CLIENT_AUTH_CERT 오류 해결 순서 ERR_BAD_SSL_CLIENT_AUTH_CERT는 사이트가 클라이언트 인증서를 요구하거나, 브라우저가 제시한 클라이언트 인증서를 서버가 받아들이지 못할 때 나타납니다. 일반 SSL 인증서 오류와 달리 사용자 인증서, mTLS, 프록시, 서버 신뢰 목록을 함께 봐야 합니다. 열기 ERR_SSL_PROTOCOL_ERROR 원인과 해결 순서 ERR_SSL_PROTOCOL_ERROR는 브라우저와 서버가 TLS 연결을 시작했지만 프로토콜, 인증서, SNI, CDN SSL 모드, 리다이렉트, 방화벽 문제로 핸드셰이크가 깨질 때 발생합니다. 단순 인증서 만료보다 범위가 넓어 SSL, 헤더, 리다이렉트를 함께 확인해야 합니다. 열기 SSL_ERROR_RX_RECORD_TOO_LONG 원인과 해결 순서 SSL_ERROR_RX_RECORD_TOO_LONG은 브라우저가 HTTPS 연결을 기대했지만 서버가 TLS가 아닌 응답을 보내거나, 443 포트와 가상호스트, 프록시, CDN SSL 모드가 어긋날 때 자주 나타납니다. 인증서만 보지 말고 포트와 실제 응답을 함께 확인해야 합니다. 열기 Cloudflare 525 SSL Handshake Failed 원인과 해결 순서 Cloudflare 525 SSL Handshake Failed는 Cloudflare 엣지가 원본 서버와 TLS 핸드셰이크를 완료하지 못할 때 나타납니다. 원본 인증서, SNI, TLS 버전, 방화벽, 443 포트, Cloudflare SSL 모드를 함께 확인해야 합니다. 열기 NET::ERR_CERT_AUTHORITY_INVALID 오류 해결 순서 NET::ERR_CERT_AUTHORITY_INVALID는 브라우저가 인증서를 발급한 인증기관을 신뢰하지 못할 때 나타납니다. 자체 서명 인증서, 누락된 중간 인증서, 사내 프록시, 보안 프로그램의 TLS 가로채기, 잘못된 체인을 분리해서 확인해야 합니다. 열기 NET::ERR_CERT_REVOKED 원인과 해결 순서 NET::ERR_CERT_REVOKED는 브라우저가 해당 SSL 인증서가 폐기되었거나 더 이상 신뢰할 수 없다고 판단할 때 나타납니다. 실제 폐기, CA 오류, OCSP/CRL 응답, 중간 인증서, 사내 프록시를 함께 확인해야 합니다. 열기 “연결이 비공개로 설정되어 있지 않습니다” 원인과 해결 순서 Chrome의 “연결이 비공개로 설정되어 있지 않습니다” 화면은 SSL 인증서 만료, 호스트명 불일치, 신뢰할 수 없는 인증기관, 폐기된 인증서, 사내 프록시, 기기 시간 오류가 섞여 나타나는 넓은 보안 경고입니다. 열기 ERR_SSL_VERSION_OR_CIPHER_MISMATCH 해결 순서 ERR_SSL_VERSION_OR_CIPHER_MISMATCH는 브라우저와 서버가 공통으로 사용할 TLS 버전이나 암호군을 찾지 못할 때 나타납니다. 오래된 TLS 설정, 약한 cipher, CDN/원본 SSL 정책 불일치, 레거시 서버 설정을 순서대로 확인해야 합니다. 열기 ERR_TOO_MANY_REDIRECTS 리다이렉트 루프 해결 순서 ERR_TOO_MANY_REDIRECTS는 브라우저가 URL을 따라가다가 다시 이전 URL로 돌아오는 리다이렉트 루프를 만났다는 뜻입니다. HTTP/HTTPS, www/비www, trailing slash, CDN SSL 모드, 애플리케이션 라우팅, 쿠키 기반 리다이렉트를 함께 확인해야 합니다. 열기 비밀번호 유출 확인 후 조치 비밀번호가 유출 데이터에 나온다면 강도가 높아 보여도 즉시 폐기해야 합니다. 같은 비밀번호를 쓴 모든 계정에서 서로 다른 새 비밀번호로 교체하고 2단계 인증을 켜는 것이 핵심입니다. 열기 SSL 인증서 오류 원인과 해결 순서 브라우저의 SSL 오류는 만료, 호스트명 불일치, 중간 인증서 누락, CDN과 원본 서버의 설정 차이에서 자주 발생합니다. 오류 화면만 보지 말고 실제 제공 인증서, 리다이렉트, 보안 헤더, DNS 경로를 함께 확인해야 합니다. 열기 보안 헤더 적용 체크리스트 HSTS, CSP, X-Frame-Options, Referrer-Policy, Permissions-Policy는 검색 신뢰도와 브라우저 보안 모두에 영향을 줍니다. 한 번에 강하게 적용하기보다 현재 헤더를 확인하고 충돌이 적은 순서로 도입해야 합니다. 열기 DNS 이전과 네임서버 변경 체크리스트 DNS 제공업체를 바꾸거나 네임서버를 이전할 때는 A/AAAA, MX, SPF, DKIM, DMARC, CAA, DNSSEC를 빠짐없이 옮겨야 합니다. 웹만 열려도 메일, 인증서 발급, 검색 수집이 깨질 수 있습니다. 열기 DNS TTL과 캐시 때문에 변경이 늦게 보이는 이유 DNS 레코드를 바꿔도 전 세계에서 즉시 같은 값이 보이지 않는 이유는 TTL, 리졸버 캐시, 네임서버 전파, 브라우저/운영체제 캐시가 겹치기 때문입니다. 변경 실패인지 전파 대기인지 구분하려면 여러 리졸버 결과를 비교해야 합니다. 열기 메일이 스팸함으로 가는 이유와 해결 메일이 스팸함으로 가는 원인은 SPF, DKIM, DMARC뿐 아니라 발신 IP 평판, reverse DNS, 블랙리스트, 새 도메인 워밍업까지 연결됩니다. 인증 통과와 실제 수신함 도착률을 분리해서 봐야 합니다. 열기 SPF 10회 DNS 조회 초과 원인과 해결 SPF는 include, a, mx, ptr, exists 같은 메커니즘이 총 10회 DNS 조회 제한을 넘으면 permerror가 날 수 있습니다. 메일 제공자를 많이 붙인 도메인은 SPF를 압축하거나 불필요한 발송 서비스를 제거해야 합니다. 열기 DMARC 정렬 실패 원인과 해결 DMARC는 SPF 또는 DKIM이 단순히 통과했는지가 아니라 From 도메인과 정렬되는지를 봅니다. 외부 발송 서비스, 포워딩, 서브도메인 정책이 섞이면 인증은 통과해도 DMARC가 실패할 수 있습니다. 열기 DKIM selector 교체와 누락 점검 DKIM selector는 발송 서비스가 어떤 공개키를 DNS에서 찾아야 하는지 알려주는 이름입니다. 키 교체, DNS 이전, 발송 서비스 변경 때 selector가 누락되면 서명 검증이 실패하고 DMARC 정렬도 흔들릴 수 있습니다. 열기 Gmail 550 5.7.26 인증되지 않은 메일 오류 해결 Gmail의 550 5.7.26 오류는 발신 도메인의 SPF, DKIM, DMARC 인증이 부족하거나 From 도메인과 정렬되지 않을 때 자주 발생합니다. 단순히 DNS TXT를 하나 추가하는 문제가 아니라 실제 이메일 헤더와 발송 서비스 설정을 함께 확인해야 합니다. 열기 SPF PermError: 여러 SPF 레코드 오류 해결 한 호스트에 SPF TXT 레코드가 두 개 이상 있으면 수신 서버는 SPF를 정상 평가하지 못하고 PermError로 처리할 수 있습니다. 여러 발송 서비스를 쓰더라도 SPF는 하나의 v=spf1 레코드로 합쳐야 합니다. 열기 DKIM body hash did not verify 오류 해결 DKIM body hash did not verify는 메일 본문이 서명 후 변경되었거나, 잘못된 selector/키/인코딩 문제로 DKIM 검증이 실패했다는 뜻입니다. DNS 공개키만 보는 것이 아니라 실제 헤더와 발송 경로의 본문 변형을 확인해야 합니다. 열기 DMARC quarantine/reject 적용 전 점검 DMARC 정책을 none에서 quarantine 또는 reject로 올리면 사칭 메일을 줄일 수 있지만, 합법적인 외부 발송 서비스가 정렬되지 않으면 정상 메일까지 차단될 수 있습니다. 리포트와 실제 헤더를 보고 단계적으로 전환해야 합니다. 열기 MX record not found 원인과 해결 MX record not found는 도메인이 메일을 받을 메일 서버를 DNS에 공개하지 않았거나, DNS 이전 중 MX 레코드가 누락됐을 때 발생합니다. 웹사이트가 정상이어도 문의, 가입, 주문 메일 수신은 깨질 수 있습니다. 열기 SMTP 550 5.7.1 Relay access denied 오류 해결 SMTP 550 5.7.1 Relay access denied는 메일 서버가 해당 발송 또는 중계를 허용하지 않을 때 발생합니다. 인증 누락, 잘못된 SMTP 서버, 외부 릴레이 차단, SPF/DMARC 정렬, 수신 서버 정책을 순서대로 봐야 합니다. 열기 HSTS preload 적용 전 체크리스트 HSTS preload는 브라우저가 처음부터 HTTPS로만 접속하게 만드는 강한 정책입니다. 모든 서브도메인의 HTTPS 준비, 리다이렉트, 인증서 자동 갱신이 안정적이지 않으면 되돌리기 어려운 장애가 생길 수 있습니다. 열기 CAA 레코드와 인증서 발급 실패 해결 CAA 레코드는 어떤 인증기관이 도메인 인증서를 발급할 수 있는지 제한합니다. DNS 이전이나 CA 변경 후 CAA가 맞지 않으면 자동 SSL 갱신이나 새 인증서 발급이 갑자기 실패할 수 있습니다. 열기 VPN 누출 점검과 해결 방법 VPN을 켜도 DNS, WebRTC, 브라우저 지문, 쿠키, 계정 위치 신호가 실제 네트워크를 드러낼 수 있습니다. 공인 IP만 바뀌었는지보다 어떤 신호가 여전히 노출되는지 분리해서 봐야 합니다. 열기 Search Console 쿼리·페이지 CTR과 수익 정체 진단 애드센스 수익이 정체될 때 AdSense 지표만 보면 검색 유입 자체가 줄었는지, 노출은 있는데 검색 결과 클릭률이 떨어졌는지, 평균 게재순위 하락으로 돈 되는 페이지가 밀렸는지 놓치기 쉽습니다. Search Console 성과 보고서의 클릭, 노출, CTR, 평균 게재순위를 쿼리, 페이지, 국가, 기기별로 나누면 수익 정체의 검색 원인을 먼저 분리할 수 있습니다. 열기 Search Console CTR 하락 원인과 확인 순서 검색 유입이 줄었을 때는 클릭 감소를 바로 순위 하락으로 보지 말고 노출, CTR, 평균 게재순위, 쿼리, 페이지, 국가, 기기를 분리해야 합니다. Search Console 성과 보고서에서 어떤 지표가 먼저 흔들렸는지 보면 title, description, 스니펫, 색인, 모바일 화면 중 무엇을 고칠지 빨리 좁힐 수 있습니다. 열기 Google 검색 결과 제목이 다르게 보일 때 Google 검색 결과의 title link는 자동으로 생성되며 title 태그만 그대로 쓰이지 않을 수 있습니다. 화면의 H1, og:title, 큰 글자 제목, 내부 링크 앵커, 외부 링크 문구, WebSite 구조화 데이터가 서로 다른 메시지를 주면 검색 결과 제목이 예상과 다르게 표시되고 CTR이 흔들릴 수 있습니다. 열기 Meta description이 검색 스니펫에 안 나올 때 Google 스니펫은 검색어와 페이지 내용에 맞춰 자동 생성되며 meta description이 항상 그대로 표시되지는 않습니다. 설명문이 너무 일반적이거나 화면 본문, 첫 답변, 제목, 구조화 데이터와 맞지 않으면 다른 문장이 스니펫으로 선택될 수 있습니다. 열기 Google Discover 유입이 갑자기 줄었을 때 Discover 유입은 검색어 기반 Search보다 변동성이 크며, 같은 사이트라도 페이지, 국가, 날짜, 콘텐츠 유형별로 출렁일 수 있습니다. 갑자기 줄었을 때는 먼저 Search Console Discover 보고서에서 클릭과 노출이 같이 줄었는지, 특정 페이지나 국가만 흔들렸는지 확인한 뒤 이미지, 제목, 신뢰 신호, 콘텐츠 품질, 크롤 접근을 점검해야 합니다. 열기 사이트 이전 후 검색 유입이 줄었을 때 도메인, HTTPS, 경로, URL 구조를 바꾼 뒤 검색 유입이 줄었다면 단순 순위 하락보다 이전 처리 상태를 먼저 봐야 합니다. 이전은 URL 단위로 처리되므로 old URL과 new URL의 리다이렉트, canonical, sitemap, hreflang, 내부 링크, Search Console 속성, 서버 로그가 서로 맞아야 유입 회복 속도가 빨라집니다. 열기 Google 코어 업데이트 후 유입이 줄었을 때 Google 코어 업데이트와 비슷한 시점에 유입이 줄었다면 특정 태그 하나를 고치는 식으로 접근하기보다 사이트 전체의 도움이 되는 콘텐츠, 신뢰 신호, 검색 의도 적합성, 오래된 답변, 중복·얇은 페이지, 내부 연결을 함께 봐야 합니다. 먼저 실제 업데이트 기간과 하락 범위를 확인하고 기술 문제와 콘텐츠 품질 문제를 분리하세요. 열기 색인됐는데 Search Console 노출이 거의 없을 때 URL 검사에서 색인됨으로 보이더라도 검색 노출과 클릭이 보장되는 것은 아닙니다. 검색 수요가 약하거나, 페이지 의도가 불명확하거나, 내부 링크가 너무 깊거나, canonical 경쟁이 있거나, 제목과 첫 답변이 쿼리 의도에 맞지 않으면 색인된 페이지도 노출이 거의 없을 수 있습니다. 열기 AI Overview와 AI Mode 노출 자격 점검 Google의 AI Overview와 AI Mode에 보조 링크로 보이려면 별도 AI 전용 파일이나 특수 schema가 필요한 것이 아니라, 페이지가 Google Search에 색인되고 스니펫을 표시할 수 있어야 합니다. 중요한 답변이 텍스트로 보이고, robots와 noindex/nosnippet/max-snippet 제한이 의도와 맞으며, 구조화 데이터가 화면 본문과 일치해야 AI 검색 표면에서도 기회가 생깁니다. 열기 Featured snippet과 People Also Ask에 안 보일 때 Featured snippet은 사이트가 직접 표시를 요청하거나 마킹해서 얻는 기능이 아니라, Google 시스템이 검색어에 맞는 답변으로 판단할 때 선택합니다. 페이지가 색인 가능하고 스니펫 표시가 허용되며, 질문에 대한 짧은 답변, 단계, 표, 정의, 비교가 화면 본문에 명확히 있어야 일반 스니펫과 답변형 검색 표면에서 선택될 가능성이 커집니다. 열기 AI 검색 query fan-out과 답변 범위 보강 AI Mode와 AI Overview는 복잡한 질문을 여러 관련 하위 검색으로 나눠 더 다양한 출처와 하위 주제를 탐색할 수 있습니다. 한 페이지가 짧은 키워드 하나만 반복하면 복합 질문에서 빠지기 쉽습니다. 핵심 질문, 원인, 확인 순서, 비교 기준, 예외, 관련 도구, 다음 질문으로 이어지는 내부 링크를 갖춘 답변 범위가 필요합니다. 열기 Google Discover와 큰 이미지 미리보기 SEO 점검 검색 결과, Google 이미지, Discover 같은 표면에서 큰 이미지 미리보기가 약하면 같은 노출에서도 CTR과 방문 유입이 줄 수 있습니다. ipnawa는 전역 meta robots에 max-image-preview:large를 두고 있지만, 각 핵심 랜딩의 og:image, 구조화 데이터 image, HTTPS 이미지 응답, Content-Type, 크기, robots 차단까지 함께 맞아야 썸네일 신호가 안정됩니다. 열기 사이트맵 lastmod와 재크롤 신호 점검 새 글을 만들거나 기존 수익 페이지를 고쳤는데 검색 유입이 빨리 회복되지 않는다면 콘텐츠 자체보다 발견 신호가 약할 수 있습니다. Google은 사이트맵의 lastmod가 일관되고 검증 가능하게 정확할 때 재크롤 스케줄링 힌트로 사용할 수 있다고 안내하지만, 단순히 날짜만 매일 바꾸는 것은 신뢰 신호가 아닙니다. lastmod, Article dateModified, 화면의 업데이트 내용, canonical, hreflang, 내부 링크가 같은 변경을 가리켜야 합니다. 열기 Crawled - currently not indexed 원인과 해결 순서 Search Console의 Crawled - currently not indexed는 Google이 URL을 실제로 크롤했지만 지금은 색인하지 않기로 판단한 상태입니다. HTTP 200만 확인하면 부족하고, 본문 품질, 중복성, canonical, noindex, 내부 링크, 구조화 데이터, 검색 의도 일치까지 같이 봐야 합니다. 열기 Discovered - currently not indexed 원인과 해결 순서 Discovered - currently not indexed는 Google이 URL을 발견했지만 아직 크롤하지 않았거나 우선순위를 낮춘 상태입니다. 새 글 수가 늘었는데 내부 링크, sitemap lastmod, 서버 응답 속도, 중복 URL, crawl budget 신호가 약하면 이 상태가 길어질 수 있습니다. 열기 Duplicate without user-selected canonical 해결 순서 Duplicate without user-selected canonical은 Google이 여러 유사 URL을 중복으로 봤지만 사이트가 선호 canonical을 명확히 주지 않았을 때 나타납니다. 검색 결과, 정렬·필터, UTM, HTTP/HTTPS, www/비www, 언어 URL이 섞이면 핵심 페이지 신호가 분산될 수 있습니다. 열기 Alternate page with proper canonical 해석과 점검 Alternate page with proper canonical은 Google이 현재 URL을 중복 또는 대체 페이지로 보고 다른 canonical URL을 색인 대상으로 선택한 상태입니다. 의도한 결과라면 정상일 수 있지만, 중요한 랜딩이 대체 페이지로 빠졌다면 canonical, 내부 링크, sitemap, hreflang 설정을 다시 봐야 합니다. 열기 Soft 404 원인과 해결 순서 Soft 404는 URL이 200으로 응답하지만 내용상 빈 페이지, 오류 페이지, 품절/삭제 안내, 검색 결과 없음처럼 Google이 실제 404에 가깝다고 판단할 때 나타납니다. 상태코드, 본문 품질, 리다이렉트, canonical, 내부 링크를 함께 고쳐야 합니다. 열기 Search Console Redirect error 원인과 해결 순서 Redirect error는 Google이 URL을 따라가다 리다이렉트 루프, 너무 긴 체인, 잘못된 최종 URL, 차단된 URL, HTTP/HTTPS 충돌, 모바일/언어 분기 문제를 만났을 때 나타날 수 있습니다. 사용자가 보는 최종 URL과 Googlebot이 보는 최종 URL을 같게 만드는 것이 핵심입니다. 열기 LCP 느림 원인과 Largest Contentful Paint 개선 순서 LCP는 사용자가 페이지의 핵심 콘텐츠가 보였다고 느끼는 시점을 대표하는 Core Web Vitals 지표입니다. 첫 화면의 큰 제목, IP 결과 카드, 주요 이미지, 도구 설명이 늦게 보이면 검색 방문자는 기다리지 않고 이탈할 수 있습니다. 서버 응답, 리다이렉트, 렌더 차단 CSS/JS, 이미지 크기, 폰트 로딩을 함께 확인해야 합니다. 열기 INP 느림 원인과 Interaction to Next Paint 개선 순서 INP는 사용자가 클릭, 탭, 입력을 했을 때 다음 화면 반응이 얼마나 빨리 보이는지 보는 Core Web Vitals 지표입니다. IP 복사 버튼, 검색 입력, 메뉴, 도구 실행 버튼이 늦게 반응하면 페이지가 느리다고 느껴지고 재방문이 줄 수 있습니다. 긴 JavaScript 작업, 과도한 이벤트 리스너, 써드파티 스크립트, DOM 업데이트를 함께 줄여야 합니다. 열기 CLS 발생 원인과 Cumulative Layout Shift 해결 순서 CLS는 페이지를 읽는 중 콘텐츠가 갑자기 밀리는 정도를 나타내는 Core Web Vitals 지표입니다. 이미지, 폰트, 결과 카드, 동적 배너, 늦게 생성되는 위젯이 크기를 예약하지 않으면 사용자가 버튼을 잘못 누르거나 핵심 답변을 놓칠 수 있습니다. 모든 늦게 로드되는 요소에 안정적인 공간과 비율을 줘야 합니다. 열기 렌더 차단 리소스 줄이는 순서 렌더 차단 리소스는 브라우저가 첫 화면을 그리기 전에 기다려야 하는 CSS, JavaScript, 폰트, 외부 요청입니다. 필요한 스타일과 스크립트가 많아질수록 LCP와 INP가 함께 나빠질 수 있습니다. 핵심 CSS는 빠르게, 나머지 스크립트는 지연하고, 불필요한 외부 요청과 리다이렉트를 줄여야 합니다. 열기 사용하지 않는 JavaScript와 CSS 줄이는 순서 사용하지 않는 JavaScript와 CSS는 첫 화면 속도, 입력 반응성, 모바일 데이터 사용량을 동시에 나쁘게 만듭니다. 여러 도구가 있는 사이트에서는 모든 페이지에 모든 기능 코드를 싣기 쉽습니다. 페이지별 기능, 공통 기능, 지연 가능한 기능을 분리해 초기 번들과 CSS를 줄여야 합니다. 열기 TTFB 느림 원인과 서버 응답 시간 개선 순서 TTFB는 브라우저가 서버에서 첫 바이트를 받기까지 걸리는 시간입니다. TTFB가 길면 LCP도 늦어지고 Googlebot 크롤링 우선순위와 사용자 이탈에도 악영향을 줄 수 있습니다. PHP 렌더링, DNS, TLS, 리다이렉트, 캐시, 외부 API 대기 시간을 함께 분리해야 합니다. 열기 다국어 hreflang, x-default와 canonical 점검 다국어 페이지가 있는데 특정 언어 유입만 정체되거나 다른 언어 페이지가 검색에 노출된다면 콘텐츠 양보다 언어 신호가 문제일 수 있습니다. Google은 각 언어에 고유 URL을 두고 hreflang, x-default, canonical, sitemap alternate가 같은 클러스터를 가리키도록 맞추는 것을 권장합니다. 열기 콘텐츠 리프레시와 검색 유입 감소 회복 점검 신규 글을 계속 만들어도 기존 고유입 페이지가 낡으면 전체 수익이 정체될 수 있습니다. Google은 유용하고 신뢰할 수 있는 사람 중심 콘텐츠를 강조하며, 기존 콘텐츠도 필요할 때 업데이트하거나 더 이상 맞지 않으면 정리하라고 안내합니다. 단순히 날짜만 바꾸는 것이 아니라 실제 답변, 예시, 도구 연결, dateModified 신호를 함께 보강해야 합니다. 열기 구조화 데이터와 화면 답변 일치 점검 FAQ, HowTo, Article JSON-LD를 넣어도 실제 화면의 답변, 단계, 날짜, canonical과 어긋나면 검색과 AEO 신뢰 신호가 약해집니다. Google은 지원되는 구조화 데이터와 리치 결과 테스트를 기준으로 검증하고, 사용자가 보는 콘텐츠와 구조화 데이터가 같은 의미를 전달해야 합니다. 숨겨진 FAQ나 날짜만 바꾼 Article 마크업은 콘텐츠 품질을 높이기보다 신뢰 리스크가 될 수 있습니다. 열기 검색 결과 스니펫과 클릭률 회복 점검 검색 노출은 있는데 클릭률과 답변형 노출이 약하다면 검색 결과에 보이는 제목, 설명, 본문 첫 답변을 먼저 봐야 합니다. Google은 title link를 title, 화면의 주요 제목, H1, og:title, anchor, WebSite 구조화 데이터 등 여러 신호로 만들고, snippet은 주로 본문과 meta description을 바탕으로 생성합니다. nosnippet, max-snippet, data-nosnippet 같은 제한은 일반 검색, featured snippet, AI/답변형 표시 가능성에도 영향을 줄 수 있습니다. 열기 내부 링크, 크롤 깊이와 신규 콘텐츠 발견 점검 새 콘텐츠를 계속 만들어도 허브, 카테고리, 관련 글, 도구 카드에서 링크가 약하면 검색엔진이 페이지를 늦게 발견하고 사이트 내 권한 흐름도 분산됩니다. Google은 새 페이지 발견과 관련성 판단에 링크를 사용하며, 중요한 페이지는 적어도 하나 이상의 다른 페이지에서 crawlable한 `<a href>` 링크로 연결되어야 한다고 안내합니다. 내부 링크는 단순한 메뉴가 아니라 수익성 있는 콘텐츠와 도구를 연결하는 성장 인프라입니다. 열기 브랜드 엔티티, 사이트명과 운영 신뢰 신호 점검 검색 결과에서 사이트가 단순 도구 모음처럼 보이면 클릭과 AEO 신뢰가 약해질 수 있습니다. Google은 사이트명을 판단할 때 홈의 WebSite 구조화 데이터, og:site_name, title, heading 등 여러 신호를 참고하고, Organization/Logo 구조화 데이터는 조직 정보와 시각적 식별을 돕습니다. 또한 helpful content 기준은 누가 만들었고, 어떻게 만들었고, 왜 만들었는지 분명히 하라고 안내합니다. 열기 AI 답변 노출과 스니펫 제어 점검 AI Overview, AI Mode, featured snippet, 일반 검색 스니펫 노출을 기대한다면 페이지는 색인 가능하고 검색에서 스니펫 표시 자격이 있어야 합니다. Google은 `nosnippet`, `data-nosnippet`, `max-snippet`, `noindex` 같은 제어로 검색과 AI 기능에 표시되는 정보량을 제한할 수 있다고 안내합니다. 반대로 Google-Extended는 Gemini 모델 학습과 일부 grounding 사용을 제어하는 별도 robots.txt 신호이므로 검색 스니펫 제어와 혼동하면 안 됩니다. 열기 URL 파라미터, 중복 결과와 크롤 예산 점검 도구 사이트는 입력값, 검색어, 정렬, 필터, UTM, 언어 파라미터가 쉽게 얇은 중복 URL을 만듭니다. Google은 단순하고 크롤 가능한 URL 구조를 권장하고, 정렬·필터·세션 식별자 같은 파라미터가 새 콘텐츠를 제공하지 않으면 크롤 예산을 소모할 수 있다고 안내합니다. 핵심 수익 랜딩은 canonical URL로 집중시키고, 내부 링크와 sitemap도 같은 URL을 가리켜야 합니다. 열기 검색 의도와 답변형 콘텐츠 갭 점검 신규 유입이 정체될 때는 단순히 페이지 수를 늘리는 것보다 사용자가 실제로 묻는 질문, 빠른 답변, 단계형 해결 순서, 관련 도구 연결이 빠진 영역을 찾는 것이 중요합니다. Google은 사람에게 도움이 되는 고유한 콘텐츠와 검색 요청에 직접 답하는 passage를 더 잘 이해하므로, 각 도구 페이지가 어떤 질문에 답하는지 명확해야 합니다. 열기 저가치 콘텐츠와 검색 유입 정체 점검 검색 유입이 정체될 때는 페이지 자체의 답변 가치가 먼저 문제일 수 있습니다. 본문이 얇거나, 여러 페이지가 같은 설명을 반복하거나, 복제·요약 콘텐츠에 고유한 해설이 부족하거나, 프로모션이 본문보다 먼저 보이면 검색 유입과 체류 모두 약해질 수 있습니다. 열기 포트는 열려야 하는데 외부에서 안 보일 때 서버에서 서비스가 실행 중이어도 외부 포트는 방화벽, 클라우드 보안그룹, NAT, ISP 차단, 잘못된 DNS 때문에 닫힘처럼 보일 수 있습니다. 로컬 listen 상태와 공개 인터넷 접근 가능성을 분리해서 확인해야 합니다. 열기 robots.txt, noindex, canonical 충돌 해결 크롤링 차단, 색인 제외, 대표 URL 지정은 서로 다른 신호입니다. robots.txt로 막아둔 페이지에 noindex를 넣거나 canonical과 리다이렉트가 다른 곳을 가리키면 검색엔진이 의도와 다르게 처리할 수 있습니다. 열기 Open Graph 이미지가 안 보이는 원인 SNS나 메신저 공유 카드에서 이미지가 안 보이는 이유는 og:image 누락뿐 아니라 상대경로, 작은 이미지, 차단된 robots, 리다이렉트, Content-Type 오류, 플랫폼 캐시 때문일 수 있습니다. 열기 JWT 만료와 시간 오류 해결 JWT 검증 실패는 서명 오류뿐 아니라 exp, nbf, iat 시간 클레임, UTC/로컬 시간대 혼동, 서버 시계 오차, base64url 디코딩 실수에서 자주 발생합니다. 열기 JSON 파싱 오류 원인과 해결 JSON parse error는 쉼표 하나뿐 아니라 따옴표, escape, 제어문자, BOM, 잘못된 Content-Type, JSON처럼 보이는 JavaScript 객체 문법 때문에 발생합니다. 열기 CORS preflight request failed 원인과 해결 CORS preflight 실패는 OPTIONS 요청이 막히거나, 허용 method/header/origin이 맞지 않거나, 인증 리다이렉트와 401/403/429 응답에서 CORS 헤더가 빠질 때 자주 발생합니다. 브라우저 콘솔만 보지 말고 실제 preflight 응답을 분리해서 확인해야 합니다. 열기 Access-Control-Allow-Origin 헤더 누락 해결 브라우저가 cross-origin API 응답을 막는 가장 흔한 이유는 Access-Control-Allow-Origin이 없거나 요청 Origin과 일치하지 않기 때문입니다. 정상 응답뿐 아니라 오류 응답, 리다이렉트, CDN 캐시 응답에서도 같은 CORS 정책이 유지되어야 합니다. 열기 Mixed Content blocked 오류 해결 HTTPS 페이지에서 HTTP 스크립트, 이미지, iframe, API를 불러오면 브라우저가 혼합 콘텐츠를 차단할 수 있습니다. 일부 이미지는 자동 업그레이드될 수 있지만 스크립트와 API는 보안상 막히므로 리소스 URL, 리다이렉트, CSP를 함께 확인해야 합니다. 열기 Content Security Policy refused to load 오류 해결 CSP refused to load 오류는 script-src, img-src, connect-src, frame-src 같은 지시어가 실제 리소스 출처를 허용하지 않을 때 발생합니다. 보안을 낮추기보다 어떤 지시어가 막았는지 확인하고 필요한 출처만 좁게 추가해야 합니다. 열기 HTTP 429 Too Many Requests 원인과 해결 HTTP 429는 API quota, rate limit, bot protection, 로그인 실패 제한, 클라이언트 재시도 루프 때문에 발생합니다. Retry-After와 rate limit 헤더를 읽고 어떤 사용자, IP, 토큰, 경로 단위로 제한되는지 확인해야 합니다. 열기 HTTP 401 Unauthorized 원인과 해결 HTTP 401은 인증 정보가 없거나, 토큰이 만료되었거나, Authorization 헤더 형식이 틀렸거나, 쿠키/세션이 cross-origin 요청에 포함되지 않을 때 발생합니다. 권한 부족인 403과 구분해 인증 흐름부터 확인해야 합니다. 열기 SameSite 쿠키가 전송되지 않는 원인과 해결 로그인 쿠키나 세션 쿠키가 요청에 빠지는 문제는 SameSite=Lax/Strict/None, cross-site 요청, iframe, 리다이렉트, fetch credentials 설정이 맞지 않을 때 자주 발생합니다. 서버 로그만 보지 말고 브라우저가 쿠키를 보냈는지부터 확인해야 합니다. 열기 Secure 쿠키가 저장되지 않거나 전송되지 않는 원인 Secure 쿠키는 HTTPS 연결에서만 저장되거나 전송됩니다. http 페이지, 잘못된 프록시 HTTPS 감지, 혼합 콘텐츠, 리다이렉트, HSTS 설정 문제 때문에 로그인 세션이 유지되지 않는 경우가 많습니다. 열기 제3자 쿠키 차단 원인과 대체 방법 브라우저가 제3자 쿠키를 제한하면 iframe 로그인, 임베드 위젯, 결제, 분석, 광고 측정, SSO 흐름이 깨질 수 있습니다. 쿠키를 무조건 다시 허용하려 하기보다 first-party 전환, Storage Access, 토큰 기반 흐름을 검토해야 합니다. 열기 쿠키 비활성화로 로그인 세션이 사라지는 원인 사용자 브라우저에서 쿠키가 꺼져 있거나 보안 확장, 프라이빗 모드, 추적 방지 정책이 쿠키를 차단하면 로그인, 장바구니, 언어 설정, CSRF 보호가 유지되지 않습니다. 저장 실패와 전송 실패를 분리해서 확인해야 합니다. 열기 Geolocation permission denied 원인과 해결 위치 권한 거부는 사용자가 브라우저 권한을 거절했거나, HTTPS가 아니거나, iframe 권한 정책, OS 위치 서비스, 브라우저 추적 방지 때문에 발생할 수 있습니다. IP 위치와 브라우저 위치 권한은 서로 다른 신호입니다. 열기 자바스크립트 비활성화로 사이트가 동작하지 않는 원인 자바스크립트가 꺼져 있거나 확장 프로그램, CSP, mixed content, 광고 차단 규칙이 스크립트를 막으면 버튼, 로그인, 폼, 계산기, API 호출이 멈출 수 있습니다. JS 비활성화와 JS 로드 실패를 분리해 확인해야 합니다. 열기 Googlebot이 robots.txt로 차단되는 원인과 해결 중요 페이지나 이미지, JSON-LD 리소스가 robots.txt에서 막히면 크롤링, 색인, 리치결과, 파비콘 표시가 흔들릴 수 있습니다. 브라우저에서 보이는 화면과 Googlebot이 접근 가능한 URL은 따로 확인해야 합니다. 열기 meta robots noindex가 발견될 때 해결 순서 noindex는 페이지를 검색 결과에서 제외하라는 강한 신호입니다. 템플릿 기본값, HTTP X-Robots-Tag, staging 설정, 플러그인, canonical 충돌 때문에 공개 페이지에 남아 있으면 색인이 멈출 수 있습니다. 열기 Google이 선택한 canonical URL이 다른 이유 Google은 페이지의 rel canonical을 참고하지만, 중복 콘텐츠, 내부 링크, sitemap, 리다이렉트, hreflang, HTTP 상태가 충돌하면 다른 URL을 대표 URL로 선택할 수 있습니다. 선언한 canonical과 실제 신호를 맞춰야 합니다. 열기 리치결과가 검색에 표시되지 않는 원인 구조화 데이터가 유효해도 Google 검색의 리치결과 표시가 보장되지는 않습니다. 페이지 접근성, 콘텐츠 품질, 구조화 데이터 정책, 이미지 접근성, visible content 일치, manual action 여부를 함께 봐야 합니다. 열기 구조화 데이터 validation 오류 해결 순서 구조화 데이터 오류는 JSON 문법, 잘못된 @type, 필수 속성 누락, 날짜 형식, 이미지 접근성, canonical 불일치 때문에 발생합니다. JSON-LD 자체와 실제 페이지 본문을 함께 검증해야 합니다. 열기 Google 검색결과에 favicon이 안 보이는 원인 검색결과 favicon은 홈 페이지의 icon 링크, 안정적인 favicon URL, 정사각형 이미지, Googlebot과 Googlebot-Image 접근성, 브랜드 대표성 같은 조건을 함께 봅니다. 설정 직후 바로 반영되지 않을 수도 있습니다. 열기 내 IP 결과 해석: 현재 연결, IPv4, IPv6, 위치 차이 IP 확인 도구는 단순히 주소 하나를 보여주는 페이지가 아닙니다. 현재 연결, 감지 가능한 IPv4/IPv6, ISP, ASN, 대략적인 위치를 분리해서 읽으면 VPN 적용 여부, 통신사 CGNAT, IPv6 전환, 회사망 프록시, 위치 오탐을 더 정확하게 판단할 수 있습니다. 열기 DNS 누출 테스트 결과 해석과 VPN 확인 순서 DNS 누출 테스트에서 보이는 resolver가 실제 ISP, VPN, 브라우저 Secure DNS, 회사 DNS 중 어디에 속하는지 구분해야 합니다. 공인 IP는 VPN으로 바뀌었는데 DNS는 ISP로 보이면 개인정보 보호 기대와 다르게 동작할 수 있습니다. 열기 VPN 체크 결과 해석: IP, DNS, WebRTC가 다를 때 VPN 체크는 공인 IP가 바뀌었는지만 보는 검사보다 넓어야 합니다. IP 위치, DNS resolver, WebRTC 후보 주소, 브라우저 지문, referrer, 쿠키·계정 위치 신호가 서로 다른 이야기를 하면 실제 프라이버시 상태도 달라질 수 있습니다. 열기 브라우저 지문 결과 해석과 추적 신호 줄이기 브라우저 지문은 IP 주소와 별개로 user agent, 언어, 시간대, 화면, WebGL, 폰트, 쿠키, WebRTC 같은 신호를 조합해 브라우저를 구분하는 방식입니다. 지문 결과를 이해하면 VPN을 켜도 왜 같은 사용자처럼 보일 수 있는지 설명할 수 있습니다. 열기 SSL 검사 결과 해석: 인증서, 체인, 만료, 호스트 불일치 SSL 검사 결과는 만료일 하나만 보는 화면이 아닙니다. 인증서 호스트명, 발급자, 체인, SAN, 프로토콜, 리다이렉트, HSTS, mixed content를 함께 읽으면 방문자 이탈을 만드는 HTTPS 문제를 더 빨리 찾을 수 있습니다. 열기 HTTP 헤더 검사 결과 해석: 상태 코드, 캐시, 리다이렉트, canonical HTTP 헤더는 페이지가 사용자와 검색봇에게 어떻게 응답하는지 보여주는 압축된 신호입니다. 상태 코드, Location, canonical, cache-control, robots, content-type, server timing을 함께 보면 색인 누락과 방문자 이탈 원인을 좁힐 수 있습니다. 열기 보안 헤더 결과 해석: CSP, HSTS, X-Frame-Options, 쿠키 보안 보안 헤더 검사 결과는 점수표보다 우선순위가 중요합니다. CSP, HSTS, X-Frame-Options, Referrer-Policy, Permissions-Policy, Secure/SameSite 쿠키를 실제 페이지 기능과 함께 읽어야 보안과 사용성을 동시에 지킬 수 있습니다. 열기 쿠키·자바스크립트 결과 해석: 로그인, 동의, 차단 확장, 저장소 문제 쿠키와 자바스크립트 결과는 브라우저 기능이 켜져 있는지뿐 아니라 로그인 유지, 언어 설정, 동의 저장, iframe, 분석, 광고, 보안 토큰이 왜 사라지는지 설명하는 단서입니다. 저장 실패와 요청 전송 실패를 나눠 봐야 합니다. 열기 IP 결과 정상·주의·수정 필요 예시 IP 확인 결과는 숫자 하나보다 상태 조합이 중요합니다. 현재 연결, IPv4/IPv6, ISP, ASN, 위치, VPN 사용 여부를 정상·주의·수정 필요 예시로 나누면 방문자가 자신의 결과를 더 빨리 판단하고 다음 도구로 이동할 수 있습니다. 열기 DNS 누출 결과 정상·주의·수정 필요 예시 DNS 누출 테스트는 resolver 이름, 국가, ASN, VPN 상태, 브라우저 Secure DNS 설정을 함께 봐야 합니다. 정상·주의·수정 필요 예시를 알면 실제 누출인지, 의도한 보안 DNS인지, 회사망 정책인지 빠르게 구분할 수 있습니다. 열기 VPN 누출 체크 정상·주의·수정 필요 예시 VPN 누출 상태는 공인 IP 하나로 끝나지 않습니다. IP, DNS, WebRTC, 브라우저 지문, 언어, 시간대, 쿠키 신호를 정상·주의·수정 필요 예시로 비교하면 VPN이 실제로 어느 범위까지 보호하는지 더 정확히 알 수 있습니다. 열기 SSL 검사 결과 정상·주의·수정 필요 예시 SSL 검사 결과는 인증서 만료뿐 아니라 호스트명, SAN, 체인, 리다이렉트, HSTS, mixed content까지 함께 봐야 합니다. 정상·주의·수정 필요 예시를 알면 브라우저 경고와 검색/방문자 이탈 원인을 더 빠르게 좁힐 수 있습니다. 열기 HTTP 헤더 상태 코드 정상·주의·수정 필요 예시 HTTP 헤더 결과는 상태 코드, 리다이렉트, cache-control, canonical, robots, content-type을 한 번에 보여줍니다. 정상·주의·수정 필요 예시로 보면 색인 누락, 오래된 스니펫, 공유 이미지 오류, 방문자 이탈 원인을 더 빠르게 찾을 수 있습니다. 열기 쿠키·자바스크립트 결과 정상·주의·수정 필요 예시 쿠키와 자바스크립트 상태는 로그인 유지, 언어 설정, 동의 저장, 분석, 광고, 보안 토큰에 직접 영향을 줍니다. 정상·주의·수정 필요 예시로 나누면 브라우저 문제인지 서버 설정 문제인지 더 빨리 분리할 수 있습니다. 열기