도메인 연결 FAQ

서브디렉토리 지원 플랫폼, 카페24/아임웹/가비아 연결 방법, DNS 설정, 도메인 연결 트러블슈팅.

도메인은 어디에서 연결할 수 있나요?

도메인 탭에서 설정 가능하며, 아래 3가지 형태의 도메인 연결을 지원합니다.

서브디렉토리 (Subdirectory): example.com/blog
서브도메인 (Subdomain): blog.example.com
루트 도메인 (Root domain): example.com, help.example.com

서브디렉토리 연결은 어떤 경우에 지원하나요?

아래 6가지 경우를 정식으로 지원합니다.

NextJS: next.config.js 파일 수정을 통해 연결
Vercel: vercel.json 파일 수정을 통해 연결
AWS Amplify: Rewrites and redirects 규칙 설정을 통해 연결
Cloudflare: 연결할 호스트의 Zone·Worker·Route를 본인의 Cloudflare 계정에서 관리하고, Proxied 상태에서 기존 홈페이지가 정상 동작하는 경우 Cloudflare Worker로 연결
Webflow: Cloudflare를 사용해 리버스 프록시 서버 구현
Framer: Cloudflare를 사용해 리버스 프록시 서버 구현

대시보드의 연결 가이드에서는 위 5가지 외에 AWS CloudFront, Cloudflare, Nginx 설정 방법도 단계별로 제공합니다.

목록에 사용 중인 환경이 없다면(예: Apache) 기타 / 문의 를 선택해 주세요. 해당 웹 서버가 특정 경로를 외부 서버로 프록시할 수 있으면 커스텀 리버스 프록시 구성으로 연결 가능하며, 채팅으로 문의 주시면 연결 가능 여부를 함께 확인해 드립니다.

'사용 중인 웹 인프라' 선택은 인블로그 쪽 설정을 바꾸는 항목이 아닙니다. 선택한 환경에 맞는 설정 가이드를 보여주기 위한 화면이므로, 나중에 다른 항목을 선택해도 이미 연결된 도메인에는 영향이 없습니다.

웹 서버(Apache, Nginx 등) 앞단에 Cloudflare나 CloudFront 같은 CDN·프록시를 이미 사용 중이라면, 원 서버 종류와 관계없이 그 CDN을 선택해 주세요. 프록시 규칙은 요청이 가장 먼저 도착하는 곳에서 처리하는 것이 간단하고, 원 서버 설정을 건드리지 않아도 됩니다.

사이트를 직접 개발했는데도 서브디렉토리 연결이 가능한가요?

연결할 호스트가 본인의 Cloudflare Zone에 있고, 기존 홈페이지가 Proxied 상태에서 정상 동작한다면 가능합니다. 이 조건을 충족한 뒤에는 사이트를 무엇으로 만들었는지(PHP, 워드프레스, Apache, nginx, 자체 개발 등)는 일반적으로 상관없습니다. Cloudflare Worker가 example.com/blog 요청만 인블로그로 전달하기 때문입니다.

응답 헤더의 server: cloudflare나 Cloudflare IP가 보이는 것만으로는 충분하지 않습니다. SaaS 호스팅 업체나 다른 CDN이 자체적으로 Cloudflare를 사용해도 같은 표시가 나타날 수 있으며, 고객의 Cloudflare 계정에서 해당 Zone·Worker·Route를 관리할 수 없다면 이 가이드를 적용할 수 없습니다.

도메인 탭에서 서브디렉토리로 주소를 입력한 뒤 가이드에서 Cloudflare를 선택하면 Worker 코드와 route 값이 나옵니다.

Cloudflare 가이드 지원 범위

구분	조건
지원	본인의 Cloudflare 계정에서 해당 호스트의 Zone·Worker·Route를 관리할 수 있고, DNS 레코드가 `Proxied`인 상태에서 기존 홈페이지가 정상 동작하며, 사용할 경로가 비어 있거나 기존 콘텐츠와 URL을 이관한 경우
별도 검토 필요	현재 `DNS only`라 프록시 전환이 필요하거나, SaaS 빌더·다른 CDN/프록시·Cloudflare Access·WAF·리디렉션·원본 IP 기반 제한을 사용하는 경우
이 가이드로 연결 불가	Cloudflare가 호스팅 업체의 앞단에만 있어 본인의 계정에서 Zone·Worker·Route를 관리할 수 없거나, 레코드를 `DNS only`로 유지해야 하거나, 호스팅 업체가 Cloudflare 프록시를 지원하지 않는 경우

Cloudflare 공식 문서도 Worker Route에 활성 Zone, Worker, Proxied DNS 레코드가 필요하다고 안내합니다. SaaS 호스팅이나 다른 CDN·프록시를 함께 사용하는 경우에는 서비스별 호환성을 별도로 확인해야 합니다.

연결 전에 아래 항목도 확인하세요.

사용할 경로(예: /blog)가 이미 응답한다면, 연결 후 기존 페이지와 그 하위 URL이 인블로그 블로그로 대체됩니다. 기존 게시글이 있다면 같은 슬러그로 이관하거나 리디렉션을 준비해 검색 유입과 외부 링크가 끊기지 않게 하세요.
연결할 호스트의 DNS 레코드가 Proxied(주황색 구름) 상태여야 합니다. DNS only 상태에서는 Worker Route가 동작하지 않습니다.
레코드가 DNS only라면, 프록시를 켜는 것은 블로그 경로만이 아니라 홈페이지 전체의 전달 방식을 바꾸는 작업입니다. 홈페이지 담당자와 먼저 확인하고, 루트 홈페이지가 정상 동작하는지 검증한 뒤 진행하세요.
SaaS 빌더나 다른 CDN/프록시를 가리키는 CNAME은 SSL 오류, 리디렉션 루프, 연결 거부가 발생할 수 있습니다. 해당 서비스가 Cloudflare 프록시를 명시적으로 지원하지 않는다면 서브도메인 연결을 권장합니다.
Cloudflare Workers 플랜의 요청 한도를 초과하면 Worker Route 요청이 실패할 수 있습니다.
사이트에 이미 robots.txt가 있다면, /robots.txt Route를 추가하는 순간 인블로그가 관리하는 robots.txt로 대체됩니다. 기존 규칙은 인블로그 robots.txt 설정으로 옮겨주세요.

설정 후에는 루트 홈페이지, 블로그 경로, robots.txt를 각각 확인해야 합니다.

curl -I https://example.com/
curl -I https://example.com/blog
curl -I https://example.com/robots.txt

루트 홈페이지도 열리지 않으면 Cloudflare 프록시·SSL/TLS·원본 서버 호환 문제입니다.
루트 홈페이지는 열리지만 /blog만 열리지 않으면 Worker 배포, Route 패턴, 기존 Worker/규칙 충돌을 확인하세요.
/blog는 열리지만 /robots.txt가 예상과 다르면 기존 robots.txt 또는 Route 충돌을 확인하세요.

Cloudflare를 CDN으로만 쓰고 있는데, DNS도 Cloudflare에서 관리하는 건가요?

반드시 그런 것은 아닙니다. 호스팅 업체나 SaaS 서비스가 자체적으로 Cloudflare를 사용하면 응답 헤더나 IP에는 Cloudflare가 표시되지만, 고객은 해당 Cloudflare Zone에 접근할 수 없습니다. 이 경우 인블로그의 Cloudflare Worker 가이드를 사용할 수 없습니다.

Cloudflare 대시보드에 로그인했을 때 연결할 도메인의 Zone이 표시되고, 해당 호스트의 DNS 레코드와 Workers & Pages의 Route를 직접 생성·수정할 수 있는지 확인하세요. 이 권한이 있어야 Cloudflare 방식으로 연결할 수 있습니다.

Cloudflare 무료·Pro 플랜은 일반적으로 네임서버를 Cloudflare로 옮기는 Full setup을 사용합니다. 다른 곳에 DNS를 두고 일부 서브도메인만 프록시하는 Partial/CNAME setup은 Business 플랜 이상에서 제공됩니다.

도메인의 네임서버를 조회했을 때 *.ns.cloudflare.com이 나오면 Cloudflare Full setup일 가능성이 높습니다. 반대로 네임서버가 도메인 등록 업체에 있고 CNAME만 Cloudflare 기반 호스팅 주소를 가리킨다면, Cloudflare Partial setup인지 호스팅 업체가 Cloudflare를 사용하는 것인지 추가 확인이 필요합니다. 응답 헤더나 DNS 조회만으로 판단하지 말고 Cloudflare 대시보드에서 Zone·Worker·Route 관리 권한이 있는지를 최종 기준으로 삼으세요.

단, 도메인이 Cloudflare에 있다고 해서 모든 호스트가 프록시 상태인 것은 아닙니다. 같은 도메인 안에서도 호스트별로 프록시를 켜고 끌 수 있으므로, 연결하려는 주소의 레코드가 Proxied인지 개별로 확인해주세요.

카페24를 사용 중이어도 Cloudflare 가이드를 선택할 수 있나요?

카페24를 도메인 구매처로 쓰는지, 웹호스팅으로 쓰는지, 쇼핑몰로 쓰는지 먼저 구분해야 합니다. 같은 카페24라도 연결 조건이 다릅니다.

사용 중인 카페24 서비스	서브디렉토리 연결 판단
도메인 구매·등록만 카페24	구매처는 제한 조건이 아닙니다. 실제 네임서버와 홈페이지 호스팅 환경을 기준으로 선택하세요.
카페24 웹호스팅·매니지드 워드프레스·서버호스팅	카페24 자체를 인블로그의 정식 서브디렉토리 지원 플랫폼으로 보는 것은 아닙니다. 카페24 도움말은 외부 Cloudflare 연결이 DNS 변경으로 가능하다고 안내하지만 설정 작업을 직접 지원하지는 않습니다. DNS를 본인의 Cloudflare Zone으로 옮기고 홈페이지가 `Proxied` 상태에서 정상 동작하는지 별도로 검증한 경우에만 Cloudflare 환경으로 진행할 수 있습니다.
카페24 쇼핑몰	카페24 공식 연결 절차는 쇼핑몰 관리자에서 도메인을 연결하고 카페24 쇼핑몰 네임서버를 사용하도록 안내합니다. Cloudflare 프록시 호환성이 공식 확인되지 않았으므로 연결을 보장하지 않습니다. 서브도메인을 사용하거나 카페24에 프록시 지원 여부를 먼저 확인하세요.

카페24 웹호스팅에서 Cloudflare로 네임서버를 옮길 때는 기존 A·CNAME·MX·TXT 레코드를 빠짐없이 복사해야 합니다. 특히 메일 레코드가 누락되면 홈페이지가 열리더라도 메일이 중단될 수 있습니다. Cloudflare에서 홈페이지 레코드를 Proxied로 바꾼 뒤에는 루트 홈페이지와 로그인·결제·파일 업로드·SSL을 먼저 검증하고, 그 다음 /blog Worker Route를 추가하세요.

서브디렉토리 대신 서브도메인이나 루트 도메인을 연결할 때는 아래 DNS 설정을 사용할 수 있습니다.

카페24에서 서브도메인(CNAME) 연결하기

카페24 DNS 관리 페이지에서 CNAME 레코드를 추가할 때, 이름/호스트 입력란에는 서브도메인 전체(blog.example.com)를 입력합니다. blog만 입력하지 않습니다.

카페24에서 루트 도메인(A 레코드) 연결하기

루트 도메인(example.com) 자체를 인블로그에 연결할 경우 A 레코드를 사용합니다.

호스트 IP(A 레코드) 추가 화면에서:
- [도메인/호스트] 이름 입력란: 빈칸으로 두거나 @를 입력합니다.
- IP 주소 입력란: 인블로그에서 제공하는 A 레코드 값을 입력합니다.

DNS 변경 후 반영까지 수 분 ~ 수십 분이 소요될 수 있습니다.

아임웹은 어떤 식으로 연결 가능한가요?

아임웹은 서브 도메인 형태 (blog.example.com)로 연결 가능합니다. 서브디렉토리 연결은 따로 지원하지 않습니다. 별도의 리버스 프록시 서버를 직접 만드실 수 있다면 이론상으로는 가능하지만 정식으로 지원드리는 방법은 아닙니다.

서브 도메인 형태로 연결시에는 이름 에 blog 가 아닌 blog.example.com 과 같이 Full URL 을 넣어주시고, 값/위치 에는 맨 뒤 온점을 뺀 cname.vercel-dns.com 을 넣어주셔야 합니다.

가비아는 어떤 식으로 연결 가능한가요?

가비아에서는 서브도메인(CNAME)과 루트 도메인(A 레코드)을 설정할 수 있습니다. 서브디렉토리(example.com/blog) 연결은 DNS 설정만으로는 불가능하며, 위 서브디렉토리 연결은 어떤 경우에 지원하나요? 항목의 환경이거나 직접 리버스 프록시 서버를 구축할 수 있는 경우에만 가능합니다.

CNAME 값 끝에 온점(.)을 붙여야 합니다

가비아 DNS 설정에서 CNAME 레코드를 저장하려고 하면 CNAME 타입의 '값/위치'는 점(.)으로 끝나야 합니다 라는 오류가 뜰 수 있습니다. 가비아는 값을 완전한 도메인 이름(FQDN) 형식으로 요구하기 때문입니다.

이 경우 인블로그가 안내한 값 맨 뒤에 온점을 추가 해서 등록해 주세요.

예: 인블로그 안내 값이 abc123.vercel-dns-016.com 이라면
가비아 입력 값: abc123.vercel-dns-016.com.

DNS 서비스마다 요구 형식이 다릅니다. 아임웹처럼 맨 뒤 온점을 빼야 하는 곳도 있으니, 오류 메시지에 안내된 형식을 따라 주세요.

서브도메인이나 루트 도메인 연결 시 어디에 DNS 설정값을 넣어야 하나요?

홈페이지를 만든 서비스(아임웹, Framer 등)와 도메인을 구매·관리하는 서비스(가비아, 카페24 등)는 다를 수 있습니다. DNS 설정은 도메인을 구매하거나 네임서버를 관리하는 곳에서 해야 합니다. 블로그를 올린 플랫폼에서 하는 것이 아닙니다.

예를 들어, 아임웹으로 홈페이지를 만들었지만 도메인은 카페24에서 구매했다면 → DNS 설정은 카페24에서 해야 합니다.

도메인을 연결하려면 먼저 dnschecker.org/ns-lookup.php에서 연결할 도메인의 최상단 주소(예: blog.example.com → example.com)를 입력해 네임서버 를 확인합니다.

도메인 구매처 (가비아, Namecheap, GoDaddy 등) 또는
네임서버를 옮긴 업체 (AWS Route53, Cloudflare, 카페24 등)

에서 설정해야 합니다. 인블로그 도메인 연결 가이드에 나오는 DNS 레코드 를 추가해주시면 되며, 추가된 레코드는 dnschecker.org/all-dns-records-of-domain.php에서 확인할 수 있습니다.

일부 경우에는 CNAME 레코드 외에도 TXT 레코드 를 추가해야 하며, 이때는 두 레코드를 모두 DNS에 등록해야 정상적으로 동작합니다.

기본 도메인(inblog.io)과 커스텀 도메인의 SEO 차이는 무엇인가요?

인블로그 기본 도메인(xxx.inblog.io)만 사용할 경우, 검색 순위·백링크·도메인 신뢰도 등 SEO 성과는 inblog.io 도메인에 귀속됩니다. 특정 분야의 전문성을 구글에 인식시키기 어렵고, 나중에 커스텀 도메인으로 이전하면 SEO 성과를 처음부터 다시 쌓아야 할 수 있습니다.

커스텀 도메인을 연결하면 SEO 성과가 내 도메인에 직접 쌓입니다. 블로그를 오래 운영할수록, 또 브랜드·비즈니스용으로 활용할수록 커스텀 도메인 연결이 유리합니다. 기본 도메인으로 먼저 시작했더라도, 커스텀 도메인 연결 시 자동 리디렉션과 캐노니컬 이전이 제공됩니다.

도메인 연결 없이 블로그를 사용하다가, 추후에 연결할 수 있나요?

네, 가능합니다.

처음에는 인블로그 기본 도메인으로 사용하시다가, 이후에 커스텀 도메인을 연결할 수 있습니다.
커스텀 도메인 연결이 완료되면, 기존 기본 도메인 URL(xxx.inblog.io/...)로 들어오는 모든 요청이 커스텀 도메인으로 308(영구) 리디렉션 됩니다. 별도 설정 없이 자동으로 작동하며, 경로(path)와 쿼리 파라미터도 그대로 유지됩니다.
리디렉션과 함께 캐노니컬 URL도 커스텀 도메인으로 이전되어, 기존에 기본 도메인으로 쌓인 구글 색인이 자연스럽게 커스텀 도메인으로 전환됩니다.

서브도메인으로 쓰던 블로그를 서브디렉토리로 옮길 수 있나요?

네, 가능합니다. 도메인 탭에서 연결 방식을 서브디렉토리로 바꾸고 새 주소(예: example.com/blog)를 등록하면 됩니다. 다만 블로그 하나에 적용되는 연결 방식은 한 번에 하나라, blog.example.com과 example.com/blog를 동시에 운영할 수는 없습니다.

자동으로 따라오는 것

글의 슬러그는 바뀌지 않습니다. 주소에서 호스트와 앞부분 경로만 달라지고 글마다 별도 작업은 필요 없습니다.
캐노니컬 URL, 사이트맵, RSS, 카테고리·작성자 페이지 주소는 새 연결 방식이 확인되면 새 주소 기준으로 자동 생성됩니다(캐시 반영에 수 분이 걸릴 수 있습니다).
API·CLI 자동화(Make, Zapier, n8n 등)는 영향을 받지 않습니다. API 키는 커스텀 도메인이 아니라 블로그 자체에 연결되어 있어 도메인 연결 방식을 바꿔도 그대로 동작합니다.

직접 처리해야 하는 것

기존 커스텀 서브도메인(blog.example.com)의 301 리디렉션은 직접 설정해야 합니다. 연결이 해제되면 그 주소는 더 이상 인블로그가 응답하지 않으므로, 도메인·호스팅을 관리하는 곳에서 blog.example.com/{슬러그} → example.com/blog/{슬러그} 규칙을 걸어 주세요. 슬러그가 그대로이므로 호스트를 바꾸고 앞에 /blog를 붙이는 규칙 하나로 처리할 수 있습니다.
이때 blog.example.com의 DNS 레코드를 인블로그 쪽에서 먼저 떼어내야 리디렉션 규칙이 동작합니다. 기존 CNAME이 그대로 남아 있으면 요청이 계속 인블로그로 향해 규칙이 적용되지 않습니다.
기본 도메인(xxx.inblog.io)에서 커스텀 도메인으로 보내는 자동 리디렉션은 서브도메인·루트 도메인 연결을 기준으로 동작합니다. 서브디렉토리 연결에서는 전환 직후 바로 적용되지 않을 수 있으니, 기본 도메인 주소가 색인되어 있다면 전환 후 실제 응답을 확인해 주세요.

전환 중 블로그가 멈추나요?

새 프록시 설정이 확인되기 전까지는 기본 도메인(xxx.inblog.io)으로 계속 접속할 수 있고, 확인이 끝나면 새 주소로 자동 전환됩니다. 기존 홈페이지는 인블로그가 관여하지 않으므로 /blog 경로 규칙을 추가하는 작업 외에는 영향을 받지 않습니다.

주소가 바뀌면 검색엔진이 새 주소를 다시 색인하는 데 시간이 걸립니다. 기존 주소의 301 리디렉션이 색인과 유입을 넘겨주는 핵심이므로 반드시 함께 설정해 주세요.

서브디렉토리로 연결할 경우, 기존 홈페이지의 GNB 영역을 인블로그 상단에 살릴 수 있나요?

가능합니다.

인블로그 대시보드의 디자인 탭에서 제공하는 GUI 편집 기능 이상으로 커스터마이징이 필요하다면, 커스텀 코드 삽입 기능 을 활용할 수 있습니다.
HTML과 CSS를 헤더 영역에 삽입하여, 기존 홈페이지의 GNB 영역과 유사하게 구현하실 수 있습니다.

서브디렉토리로 연결할 경우, 개발 공수는 어느 정도 드나요?

상황에 따라 다릅니다.

내부에 웹 개발자가 계시고, 인블로그에서 제공하는 가이드를 따른다면 30분 이내에도 작업이 가능 합니다.
다만, 인블로그 자체에서 도메인을 직접 관리하지 않기 때문에, 해당 도메인을 호스팅하는 웹서버 측에서 프록시 연결을 설정 해야 합니다.
따라서 사용 중인 웹서버/웹 프레임워크가 특정 서브디렉토리를 외부 서버로 프록시 연결할 수 있는지 확인이 필요합니다.
개발 인력이 부족하거나 연결 가능 여부 판단이 어려우실 경우, 채팅으로 문의해 주시면 저희가 연결 가능 여부 확인과 지원을 드릴 수 있습니다.

블로그 목록에서 도메인이 '인증되지 않음'으로 표시됩니다. 어떤 의미인가요?

인블로그 대시보드의 블로그 목록에서 '인증되지 않음' 상태는 인블로그가 아직 해당 도메인의 DNS 레코드를 확인하지 못했다는 의미입니다. 다음 경우에 해당할 수 있습니다.

DNS 레코드가 아직 입력되지 않았거나 값이 잘못되었습니다.
DNS 변경 후 전파 시간(최대 24~48시간)이 아직 지나지 않았습니다.

'인증됨'으로 표시되면 DNS 확인이 완료된 것입니다. 이후 실제 접속이 되기까지 수십 분이 추가로 걸릴 수 있습니다.

도메인 탭에 `SSL 인증서 발급 중`이 표시됩니다. 기다리면 되나요?

대부분은 기다리시면 됩니다. 도메인에 CAA 레코드를 설정해 둔 경우가 아니라면 추가로 하실 일은 없습니다. SSL 인증서 발급 중은 DNS 레코드가 정상으로 확인된 뒤 HTTPS 준비만 남은 단계에서 표시됩니다. 레코드 입력은 이미 통과한 상태라는 뜻입니다.

서브도메인·루트 도메인으로 연결한 경우, 도메인 탭의 연결 상태는 다음 네 가지로 표시됩니다.

상태	의미	해야 할 일
`DNS 레코드 설정 필요`	안내된 레코드가 아직 확인되지 않음	DNS 관리 화면에서 레코드 추가
`DNS 레코드 설정 확인 중`	인블로그가 지금 레코드를 조회하는 중	잠시 기다리기
`SSL 인증서 발급 중`	레코드 확인 완료, HTTPS 준비 중	기다리기
`연결됨`	연결 완료	—

서브디렉토리로 연결한 경우에는 리버스 프록시 설정 필요·리버스 프록시 연결 여부 확인 중·연결됨 세 가지로 표시됩니다.

DNS 변경은 전파에 최대 24~48시간이 걸릴 수 있고, 인증서가 발급된 뒤에도 실제 접속까지 수십 분이 더 걸릴 수 있습니다.

도메인에 CAA 레코드를 설정해 두었다면 인증서 발급이 막힐 수 있으니 함께 확인해 주세요.
하루가 지나도 SSL 인증서 발급 중에서 바뀌지 않으면 연결하려는 주소와 화면을 함께 문의해 주세요.

도메인 카드에 "이 도메인의 네임서버를 찾을 수 없습니다"가 표시됩니다

인블로그는 입력한 주소의 루트 도메인(예: blog.example.com → example.com) 네임서버를 조회해, 어느 DNS 서비스에 레코드를 넣어야 하는지 안내합니다. 이 경고는 그 조회가 아무 결과도 돌려주지 않았다는 뜻입니다. 다음을 확인해 주세요.

도메인 철자가 정확한지
도메인이 실제로 등록되어 있고 만료되지 않았는지
도메인 등록 업체에서 네임서버가 지정되어 있는지 (구매 직후에는 비어 있을 수 있습니다)

이 경고는 DNS 서비스를 자동으로 알려주기 위한 조회 결과일 뿐이고, 연결 확인 자체를 막지는 않습니다. 도메인이 실제로 네임서버 없이 방치된 상태라면 레코드를 추가해도 조회되지 않으니 등록 업체에서 네임서버 설정을 먼저 마쳐 주세요. 반대로 레코드를 추가한 뒤 연결이 정상적으로 진행된다면 이 경고는 무시하셔도 됩니다.

DNS 설정을 했는데도 커스텀 도메인이 연결되지 않습니다. 어떻게 해야 하나요?

DNS 연결이 되지 않는 경우 다음 사항을 확인해 주세요.

1. DNS 레코드 값 확인

CNAME과 TXT 레코드가 인블로그에서 안내한 값과 정확히 동일한지 확인합니다.

예시

CNAME

유형: CNAME
이름: blog
값: f249333e8f94923b.vercel-dns-016.com

TXT

유형: TXT
이름: _vercel
값: vc-domain-verify=blog.domain.com,xxxxxxxx

2. TXT 레코드 입력 형식 오류

DNS 설정 시 다음과 같은 문제가 자주 발생합니다.

http:// 프로토콜이 포함됨
= 또는 , 문자가 누락됨
DNS 서비스에서 자동으로 문자열이 변경됨

TXT 레코드는 안내된 문자열 그대로 입력해야 합니다.

3. 기존 DNS 레코드 충돌

이전에 설정된 A 레코드나 CNAME 레코드 등이 남아 있으면 충돌이 발생할 수 있습니다.

4. DNS 전파 시간

DNS 변경 사항은 최대 24~48시간 정도 전파 시간이 필요할 수 있습니다.

저는 접속되는데 다른 사람은 블로그가 열리지 않습니다. 왜 그런가요?

대시보드 도메인 상태가 인증됨이고 내 환경에서는 정상적으로 열리는데 링크를 받은 사람만 접속되지 않는 경우가 있습니다. 이때는 도메인 설정 문제가 아니라, 그 사람이 쓰는 네트워크(가정용 Wi-Fi, 통신사, 회사망)의 DNS 캐시에 이전 상태가 남아 있는 경우가 대부분입니다. DNS 변경 사항은 최대 24~48시간 동안 네트워크마다 다른 속도로 반영되기 때문에, 공개 DNS에서는 이미 정상인데 일부 네트워크에서만 주소를 찾지 못할 수 있습니다.

이렇게 대응해 주세요.

블로그를 공유할 때는 전체 주소(예: https://blog.example.com)를 그대로 전달합니다.
열리지 않는 분은 Wi-Fi 대신 모바일 데이터로 접속해 보거나, 잠시 후 다시 시도합니다.
24~48시간이 지난 뒤에도 특정 환경에서만 열리지 않으면, 그 환경에서 접속한 정확한 주소와 표시된 오류 화면을 함께 보내 문의해 주세요.

AWS CloudFront로 서브디렉토리를 연결하는 방법은?

AWS CloudFront로 인블로그를 서브디렉토리에 연결하려면 아래 설정 항목을 확인해주세요.

메인 웹사이트를 서비스 중인 기존 distribution을 사용하거나, 아직 CloudFront가 설정되어 있지 않다면 새 distribution을 생성하세요.
Distribution name은 inblog proxy, Domain은 example.com으로 설정하세요.
Origin type은 Other, Custom origin은 proxy.inblog.dev, Origin path는 /{subdomain}으로 설정하세요.
CloudFront가 방문자의 Host 헤더를 proxy.inblog.dev로 전달하지 않도록 origin request policy를 Managed-AllViewerExceptHostHeader로 설정하세요.
URI 재작성을 위한 CloudFront Function을 만들고 아래 코드를 붙여넣으세요.

function handler(event) {
  var request = event.request;
  var uri = request.uri;
  var basePath = "/blog";

  if (basePath === "/") {
    return request;
  }

  if (uri === basePath) {
    request.uri = "/";
    return request;
  }

  if (uri === basePath + "/") {
    request.uri = "/";
    return request;
  }

  if (uri.startsWith(basePath + "/")) {
    request.uri = uri.substring(basePath.length);
    return request;
  }

  return request;
}

/blog, /blog/*, /robots.txt behavior를 추가하세요.
Function을 Live로 publish한 뒤, 세 behavior 모두의 Viewer request 이벤트에 연결하세요.

배포가 완료되면 터미널에서 아래 URL을 확인하세요.

curl -I https://example.com/blog
curl -I https://example.com/robots.txt

CloudFront로 연결했는데 502 오류가 납니다. 무엇을 확인해야 하나요?

먼저 Origin path를 비워두지 않았는지 확인해 주세요. 서브디렉토리 연결에서는 별도의 CNAME 값이 아니라 Custom origin proxy.inblog.dev + Origin path /{subdomain} 조합을 사용하는 것이 맞습니다.

설정이 위와 같은데도 502가 계속된다면 아래 항목을 순서대로 확인해 주세요. 대부분 이 중 하나가 누락된 경우입니다.

/blog, /blog/*, /robots.txt 세 behavior가 모두 proxy.inblog.dev origin을 사용하고 있는지
세 behavior 모두 origin request policy가 Managed-AllViewerExceptHostHeader인지 (Host 헤더가 그대로 전달되면 origin이 요청을 처리하지 못합니다)
CloudFront Function이 Live로 publish 되어 있는지 (저장만 하고 publish하지 않은 경우가 많습니다)
해당 Function이 세 behavior 모두 의 Viewer request 이벤트에 연결되어 있는지
마지막 변경 사항까지 포함해 distribution 배포가 완료(Deployed) 되었는지

위 항목이 모두 정상인데도 502가 계속된다면, 아래 세 명령의 응답을 함께 보내주시면 CloudFront를 거친 요청과 origin 직접 요청을 비교해 원인을 구분해 드립니다.

curl -I https://example.com/blog
curl -I https://example.com/robots.txt
curl -I https://proxy.inblog.dev/{subdomain}

서브디렉토리로 연결했는데 `ERR_TOO_MANY_REDIRECTS`가 납니다.

블로그 경로가 무한 리디렉트에 빠져 아예 열리지 않는 경우입니다. 대부분 사이트에 걸린 /blog 규칙이 원인이며, 아래 두 가지가 가장 흔합니다.

1. redirect가 아니라 rewrite여야 합니다

/blog를 인블로그로 넘길 때는 주소를 바꾸지 않고 내부적으로 대신 응답하게 하는 rewrite(리버스 프록시) 를 사용해야 합니다. redirect로 설정하면 /blog 요청이 같은 /blog 주소를 다시 가리키게 되어 자기 자신을 무한히 반복합니다.

/blog       →  https://proxy.inblog.dev/{subdomain}
/blog/:path*  →  https://proxy.inblog.dev/{subdomain}/:path*

2. 인블로그에 등록한 주소와 사이트 정규 주소의 www 여부가 다릅니다

사이트 본체는 example.com(non-www)을 정규 주소로 쓰면서 인블로그에는 www.example.com/blog로 등록해 두면, www와 non-www 사이에서 리디렉트가 서로를 되받아 순환합니다. 둘 중 하나로 통일해 주세요.

인블로그 도메인 탭에 등록한 주소를 사이트 정규 주소와 같은 형태로 맞춥니다.
www → non-www 통일은 /blog 전용 규칙이 아니라, 호스팅(예: Vercel)의 도메인 리디렉션 설정에서 한 방향으로만 적용합니다.

원인을 구분하는 방법

각 주소의 응답 헤더를 비교하면 어느 쪽 문제인지 바로 드러납니다. 마지막 명령이 200이면 인블로그 쪽은 정상이고 사이트의 리디렉트 규칙만 손보면 됩니다. 반대로 마지막 명령이 200이 아니라 3xx로 응답한다면 인블로그 쪽 확인이 필요하니 그 결과를 채팅으로 보내 주세요.

curl -I https://example.com/blog
curl -I https://www.example.com/blog
curl -I https://proxy.inblog.dev/{subdomain}

도메인 카드에 "도메인은 연결된 상태지만 최근 리버스 프록시 확인에서 예상한 응답을 받지 못했습니다" 경고가 함께 표시된다면 같은 원인일 수 있습니다. 이 경고는 리디렉트 루프 외에 방화벽 차단이나 일시적 응답 실패로도 표시될 수 있으며, 프록시 규칙이 정상화되면 다음 확인에서 자동으로 해제됩니다.

서브디렉토리로 연결하면 기존 robots.txt가 사라지나요?

연결 가이드에는 블로그 경로(/blog, /blog/*)와 함께 /robots.txt도 인블로그로 프록시하는 규칙이 포함되어 있습니다. 이 규칙은 기존 robots.txt가 없는 사이트를 위한 것입니다. 이미 자체 robots.txt를 운영 중이라면 그대로 적용하지 마세요.

robots.txt는 도메인 루트에 하나만 존재하고 그 하위 경로 전체에 적용됩니다. 따라서 /robots.txt를 프록시하면 기존 파일 대신 인블로그가 제공하는 파일이 응답하게 되고, 기존에 넣어둔 Disallow 등의 규칙이 적용되지 않습니다.

기존 robots.txt가 있다면 아래 두 가지 중 하나를 선택하세요.

1. 프록시 규칙에서 /robots.txt만 빼기 (권장)

블로그 경로(/blog, /blog/*)의 프록시 규칙은 그대로 두고 /robots.txt 규칙만 제외합니다.
기존 robots.txt에 블로그 사이트맵 주소를 한 줄 추가합니다.

Sitemap: https://example.com/blog/sitemap.xml

기존 Disallow 규칙이 블로그 경로(/blog)를 막고 있지 않은지 확인합니다.

2. /robots.txt 프록시를 유지하고 인블로그에서 편집하기

대시보드 설정 → SEO 도구 → Robots.txt 에서 내용을 직접 편집할 수 있습니다(유료 플랜, 커스텀 도메인 연결 완료 후).
여기에 기존 규칙을 그대로 옮겨 적고, 블로그 사이트맵 줄도 함께 남겨 주세요. 저장한 내용이 그대로 example.com/robots.txt 응답으로 제공됩니다.
편집창에는 인블로그가 만든 기본값(모든 크롤러 허용 + 사이트맵 주소)이 미리 채워져 있습니다. 내용을 모두 지우고 저장하면 다시 기본값이 자동 생성됩니다.

사이트맵은 별도로 관리하지 않아도 됩니다. 프록시만 연결되어 있으면 example.com/blog/sitemap.xml은 인블로그가 글 발행·수정에 맞춰 자동으로 갱신합니다. 직접 xml 파일을 만들어 올리거나 주기적으로 갱신할 필요가 없습니다.

서브디렉토리로 연결했을 때 구글 서치콘솔은 어떻게 설정해야 하나요?

서브디렉토리 방식(예: example.com/blog)으로 연결하면 블로그 트래픽이 기존 루트 도메인 서치콘솔 속성에 포함됩니다. 블로그 데이터를 별도로 분석하고 싶다면 URL 접두어(URL prefix) 방식으로 추가 속성을 생성할 수 있습니다.

속성 유형: URL 접두어
URL: https://example.com/blog

주의: 이 추가 속성도 별도의 HTML 태그 인증이 필요합니다. 인블로그 대시보드 → 설정 탭 → 코드 삽입에서 해당 속성의 메타 태그를 추가로 등록해야 합니다.

기존 홈페이지 상단 메뉴(GNB)에 블로그 탭이나 링크를 추가하려면 어떻게 하나요?

인블로그는 기존 홈페이지의 네비게이션 메뉴를 제어할 수 없습니다. 기존 홈페이지를 만든 서비스(아임웹, Framer, WordPress 등)에서 직접 메뉴를 추가·수정해야 합니다.

추가할 링크 주소는 인블로그 블로그 주소를 사용합니다.

서브도메인 방식: https://blog.example.com
서브디렉토리 방식: https://example.com/blog

커스텀 도메인 연결 전이라면 https://example.inblog.io 형태의 기본 도메인을 임시로 사용할 수 있습니다.

인블로그 블로그 헤더의 로고를 클릭하면 홈페이지로 이동하게 하고 싶습니다.

인블로그 대시보드에서 디자인 탭 → 헤더로 이동합니다. 좌측 상단 로고 이미지와 로고 클릭 시 이동할 URL을 설정할 수 있습니다. 여기에 홈페이지 주소를 입력하면 방문자가 로고를 클릭했을 때 홈페이지로 이동합니다.

최종 업데이트 2026-08-05

이전링크 · 사이트맵 · 내부 링크 FAQ 다음콘텐츠 작성하기