맞춤 도메인이 준비 상태가 되지 않거나, 잘못된 웹사이트를 열거나, 잘못 리디렉션되거나, HTTPS/보안 오류를 표시할 때 이 가이드를 사용하세요.

먼저 문제를 찾으세요

DNS를 변경하기 전에 증상 표를 사용하세요. 보이는 현상과 일치하는 섹션부터 시작하고, 대상이 명확한 변경을 하나만 수행한 다음, 도메인 상태와 호스트명을 브라우저에서 다시 확인하세요.

도메인을 확인할 위치

빠른 참조: 이 가이드에서 볼 수 있는 용어

문제 해결 단계를 사용하기 위해 DNS 내부 동작을 이해할 필요는 없습니다. 이 정의는 용어가 익숙하지 않을 때만 참고하면 됩니다.

무엇이든 변경하기 전에

• Atoms에 표시되는 정확한 Domain Status와 모든 오류 메시지를 기록하세요.

• 어떤 변경이 결과에 영향을 주었는지 알 수 있도록 한 번에 하나의 DNS 또는 라우팅 설정만 변경하세요.

• 프로덕션 DNS 레코드를 편집하기 전에 이전 값을 기록하세요.

• 인식하지 못한다는 이유만으로 레코드를 삭제하지 마세요. MX 레코드, 메일 관련 TXT 레코드 및 관련 없는 서브도메인은 이메일 또는 다른 서비스를 지원할 수 있습니다.

• 별도의 DNS 마이그레이션이 계획되고 확인된 경우가 아니라면, 단일 확인 문제를 해결하기 위해 nameserver를 변경하지 마세요.

• 문제 해결을 위한 변경으로 정상 작동하던 웹사이트, 이메일 또는 다른 서비스가 중단되면, 회귀를 일으킨 마지막 변경만 복원하세요.

확인 및 DNS 레코드 문제

Atoms가 도메인을 확인할 수 없거나, 필요한 레코드가 누락되었거나 잘못된 것으로 보이거나, DNS를 편집했지만 도메인 상태가 변경되지 않았을 때 이 섹션을 사용하세요.

먼저 원본 DNS를 확인하세요

• Atoms에서 도메인을 열고, 필요한 각 레코드를 동일한 호스트명에 대해 공개적으로 게시된 내용과 비교하세요.

• 도메인의 authoritative nameserver를 확인하고, 해당 nameserver를 제공하는 공급자에서 DNS를 편집하고 있는지 확인하세요. nameserver가 Cloudflare를 가리키는 경우, 등록기관 DNS 패널에서만 수행한 변경은 authoritative하지 않을 수 있습니다.

• 필요한 각 레코드에 대해 레코드 유형, 호스트명/이름, 대상 또는 값, 그리고 해당 레코드가 authoritative 공급자에 실제로 존재하는지 확인하세요.

• 확인 값은 Atoms에 현재 표시되는 값과 정확히 일치해야 하며, 공개 DNS 조회에서 보여야 합니다.

불일치만 수정한 다음 다시 확인하세요

• 누락된 레코드를 생성하거나 일치하지 않는 필드만 수정하세요.

• 레코드가 잘못된 DNS 공급자에 추가되었다면, 대신 authoritative 공급자에 추가하세요.

• 현재 Atoms 값을 다른 프로젝트, 다른 도메인, 오래된 스크린샷 또는 이전 Help Center 문서의 주소나 확인 값으로 바꾸지 마세요.

• 변경 사항이 공개된 후 Domains → Manage로 돌아가 Domain Status를 다시 확인한 다음, 브라우저에서 호스트명을 테스트하세요.

라우팅, 오래된 콘텐츠, 충돌하는 레코드 및 Cloudflare

호스트명이 오래된 웹사이트를 열거나, 잘못된 대상으로 연결되거나, 동일한 호스트명에 대해 여러 라우팅 레코드가 있을 때 이 섹션을 사용하세요.

정확한 호스트명에 대한 A, AAAA 및 CNAME 레코드를 확인하세요

• 이전 호스팅 공급자의 레코드, 오래된 IPv6 AAAA 대상, 동일한 호스트명에 대한 CNAME과 다른 대상 레코드의 조합, 또는 트래픽을 서로 다른 서비스로 보내는 중복 레코드를 찾으세요.

• 현재 Atoms 설정과 충돌한다고 확인된 웹사이트 라우팅 레코드만 제거하세요. 정리 목적으로 알 수 없는 레코드를 삭제하지 마세요.

• DNS가 이미 의도한 대상으로 향하고 있는데 오래된 콘텐츠가 표시된다면, DNS를 다시 변경하기 전에 비공개/시크릿 창, 다른 브라우저 또는 기기, 그리고 다른 네트워크에서 테스트하세요.

Cloudflare 프록시 상태

• TXT 확인 레코드는 DNS 전용이며 웹 프록시 레코드가 아닙니다.

• A 또는 CNAME 레코드의 경우, Atoms 인터페이스 또는 Atoms Support가 구체적으로 요구할 때만 Proxy Status를 변경하세요. 일반적인 문제 해결 단계로 레코드를 Proxied와 DNS only 사이에서 전환하지 마세요.

• Atoms 또는 Support가 프록시 상태 변경을 요청하면, 지정된 라우팅 레코드만 변경하고 새 DNS 응답이 보일 때까지 기다린 다음, 도메인과 HTTPS를 다시 테스트하세요.

DNS 전파 및 로컬 캐싱

authoritative DNS가 이미 올바른데도 서로 다른 네트워크나 기기에서 여전히 다른 결과가 표시된다면, 남아 있는 문제는 보통 새로운 구성 오류가 아니라 캐싱입니다.

• authoritative DNS 결과를 하나 이상의 공개 DNS resolver와 비교하고, 필요하다면 모바일 데이터 같은 다른 네트워크와도 비교하세요.

• authoritative DNS가 잘못되었다면 원본 레코드를 수정하세요. authoritative DNS는 올바르지만 다른 resolver가 여전히 이전 값을 반환한다면, 레코드를 반복해서 편집하지 마세요.

• DNS 변경이 전 세계적으로 보이기까지 최대 48시간이 걸릴 수 있지만, 보통은 더 빨리 반영됩니다.

• DNS와 Atoms가 다른 곳에서는 올바른데 브라우저 또는 기기 하나에서만 잘못된 결과가 표시된다면, 해당 로컬 브라우저/네트워크 캐시를 지우거나 우회하세요. 기기별 캐시 문제 때문에 DNS를 변경하지 마세요.

• 나중에 다시 확인하고 공개 resolver가 동일한 의도된 값으로 수렴하는지 살펴보세요.

SSL / HTTPS 문제

DNS는 올바르게 보이지만 HTTPS를 발급할 수 없거나, 브라우저에 인증서 경고가 표시되거나, 이전에는 작동하던 HTTPS가 الآن 실패할 때 이 섹션을 사용하세요.

인증서 주변 구성을 확인하세요

• 정확한 브라우저 오류와 열고 있는 정확한 호스트명을 기록하세요.

• DNS 라우팅, 전파, Cloudflare 프록시 상태, 그리고 인증서가 다른 호스트명에 속한 것으로 보이는지 확인하세요.

• 최근 DNS, nameserver, Cloudflare 프록시 설정, CAA 레코드 또는 프로젝트/도메인 연결에서 변경된 사항이 있는지 확인하세요.

• 제한적인 인증서 정책이 있을 수 있다면 영향을 받는 호스트명과 상위 도메인의 CAA 레코드를 확인하세요.

수정 및 확인

• 확인된 DNS, 프록시, CAA, 호스트명 또는 프로젝트 연결 문제만 수정하세요.

• 일반적인 해결책으로 브라우저 인증서 경고를 우회하지 마세요.

• 공개 DNS가 올바르고 사용자 제어 구성으로 실패 원인을 설명할 수 없다면, DNS 변경을 중단하고 인증서 프로비저닝 또는 갱신을 위해 Atoms Support에 문의하세요.

• Atoms가 구체적으로 지시하지 않는 한, 인증서 갱신을 강제하기 위해 그 외에는 올바른 DNS를 교체하지 마세요.

• https:// 를 사용해 정확한 호스트명을 열고, 의도한 프로젝트가 인증서 경고 없이 로드되는지 확인하여 다시 점검하세요.

루트, www, 리디렉션 및 잘못된 프로젝트 동작

이 문제들은 기본 연결이 이미 작동하고 있어도 DNS 또는 SSL 실패처럼 보일 수 있으므로 여기서 확인할 가치가 있습니다.

루트는 작동하지만 www는 작동하지 않음 — 또는 그 반대

• example.com과 www.example.com을 별도의 호스트명으로 취급하세요. 둘 다 HTTPS로 테스트하세요.

• 실패하는 호스트명의 DNS 결과와 Atoms Domain Status를 확인하세요.

• 루트 도메인 값을 단순히 www에 복사하면 된다고 가정하지 마세요.

호스트명을 아직 연결하거나 다시 구성해야 한다면, 여기서 구성 절차를 복제하지 말고 Connect and Manage Domains의 설정 단계를 따르세요.

리디렉션이 잘못된 주소로 이동하거나 반복 루프가 발생함

• 방문자가 최종적으로 도달해야 한다고 예상하는 주소를 확인하고, 새 비공개 브라우저 세션에서 리디렉션을 테스트하세요.

• 등록기관 포워딩, Cloudflare 리디렉션 규칙, 다른 프록시/CDN 또는 이전 호스팅 플랫폼처럼 다른 시스템도 리디렉션을 수행하고 있는지 확인하세요.

• 충돌이 확인된 리디렉션 계층만 변경하세요. 여러 리디렉션 시스템을 동시에 변경하지 마세요.

• 변경으로 리디렉션 루프가 생기거나 방문자가 잘못된 대상으로 이동하면, 다른 계층을 테스트하기 전에 이전에 작동하던 리디렉션 구성을 복원하세요.

연결된 주소 중 어떤 것을 기본으로 할지 변경하려면 Connect and Manage Domains의 절차를 사용하세요.

도메인이 잘못된 Atoms 프로젝트를 엶

• DNS가 이미 Atoms에 올바르게 도달하고 있다면, DNS를 반복해서 변경하기보다 프로젝트/도메인 연결 문제로 취급하세요.

• 현재 어떤 프로젝트 또는 워크스페이스에 도메인 연결이 표시되는지 확인하세요.

• 연결이 수정된 후, 호스트명이 의도한 프로젝트를 열고 HTTPS도 계속 작동하는지 다시 확인하세요.

전환, 연결 해제, 재연결 또는 프로젝트 간 도메인 이동은 Connect and Manage Domains를 따르세요. 현재 연결이 접근할 수 없거나 삭제된 프로젝트/워크스페이스/계정에 속해 있다면, 추가 DNS 변경을 하지 말고 Atoms Support에 문의하세요.

DNS 변경을 중단하고 Atoms Support에 문의해야 하는 경우

증거가 Atoms 측 상태, 인증서 또는 연결 문제를 가리킨다면 DNS 편집을 계속하지 말고 에스컬레이션하세요.

• DNS가 올바르다고 확인되었지만 Atoms 도메인 상태가 복구되지 않습니다.

• 공개 DNS와 사용자 제어 설정이 올바른데도 인증서 프로비저닝 또는 갱신이 실패합니다.

• 도메인이 접근할 수 없거나 삭제된 프로젝트/워크스페이스/계정에 연결되어 있거나, 관련 도메인 관리 작업이 실패합니다.

• 서로 관련 없는 여러 Atoms 도메인이 동시에 실패하고, 해당 DNS 레코드는 최근 변경되지 않았습니다.

• 문제 해결을 위한 변경이 다른 서비스에 영향을 주었고, 올바른 롤백을 안전하게 식별할 수 없습니다.

에스컬레이션 전에 이 증거를 준비하세요

• 영향을 받는 호스트명과 의도한 Atoms 프로젝트/워크스페이스.

• 현재 표시되는 정확한 Domain Status 또는 오류 메시지.

• 현재 authoritative DNS 결과와 Atoms가 현재 요구하는 값.

• 해당하는 경우 브라우저의 정확한 HTTPS/인증서 오류.

• 마지막으로 수행한 변경과, 이를 복원했을 때 이전 동작으로 돌아갔는지 여부.

최종 재확인

수정 후에는 Domains → Manage로 돌아가 Domain Status를 다시 확인하세요. 그런 다음 브라우저에서 결과를 확인하세요.

• 의도한 호스트명이 연결되어 있고 의도한 Atoms 프로젝트에 도달합니다.

• HTTPS가 인증서 경고 없이 작동합니다.

• 루트와 www가 의도한 대로 동작합니다.

• 리디렉션이 의도한 주소에서 끝납니다.

• DNS 변경 후에도 이메일 및 기타 관련 없는 서비스가 계속 작동합니다.

FAQ