도메인 연결 FAQ

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

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

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

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

화면까지 가는 경로는 다음과 같습니다.

1. inblog.ai/dashboard 에 로그인하면 내 블로그 목록이 나옵니다.
2. 설정할 블로그 카드를 클릭합니다. 도메인은 블로그마다 따로 설정하므로, 여러 개를 운영 중이라면 대상 블로그가 맞는지 먼저 확인해 주세요.
3. 좌측 메뉴의 설정 그룹 아래에 있는 도메인 을 클릭합니다. (설정 화면을 열어 그 안에서 찾는 것이 아니라, 좌측 메뉴에서 도메인 을 직접 누르시면 됩니다.)
4. 도메인 화면 상단의 서브디렉토리 · 서브도메인 · 루트 도메인 탭 중 원하는 방식을 고른 뒤 주소를 입력하고 연결 시작하기 를 누릅니다. 서브디렉토리 탭에서는 이어서 사용 중인 웹 인프라를 고르면 그에 맞는 프록시 설정 가이드가 단계별로 표시됩니다.

도메인 화면이 흐리게 표시되고 입력이 되지 않는다면 무료 플랜 블로그입니다. 커스텀 도메인 연결은 팀 플랜(14일 무료 체험 포함)에서 사용할 수 있습니다.

카드를 눌렀는데 관리 화면이 아니라 초기 설정 화면이 열린다면 도메인 연결도 그 화면의 안내를 따라 진행하시면 됩니다. 자세한 내용은 인블로그 시작하기의 초기 설정 화면 설명을 참고해 주세요.

서브도메인 앞의 blog. 를 다른 이름으로 바꿀 수 있나요?

네, 가능합니다. 다만 서브도메인 탭이 아니라 루트 도메인 탭에서 입력하셔야 합니다.

서브도메인 탭은 입력란 앞에 https://blog. 가 고정으로 붙어 있어, 여기에 example.com 을 넣으면 언제나 blog.example.com 으로만 연결됩니다. 이 blog. 부분은 화면에서 바꿀 수 없습니다.

news.example.com, insight.example.com 처럼 다른 이름을 쓰고 싶다면 루트 도메인 탭을 선택하고 원하는 주소 전체(news.example.com)를 입력해 주세요. 이 탭은 https:// 뒤를 그대로 받기 때문에 최상위 도메인뿐 아니라 원하는 서브도메인도 넣을 수 있습니다. 위 목록의 루트 도메인 예시에 help.example.com 이 함께 적혀 있는 것도 같은 이유입니다.

이때 화면에 안내되는 DNS 레코드의 이름은 그대로 쓰지 마세요. 루트 도메인 탭은 최상위 도메인을 연결하는 경우를 기준으로 안내하기 때문에, 레코드가 표시된다면 보통 이름이 도메인 전체를 뜻하는 @ 인 A 레코드로 나옵니다. 서브도메인을 연결하는 경우에는 그 자리에 실제로 쓸 서브도메인을 넣어 주세요. @ 로 그대로 넣으면 레코드가 최상위 도메인에 걸려, 정작 연결하려는 주소는 계속 확인되지 않습니다.

이름을 적는 형식은 DNS 업체마다 다릅니다. 라벨만 받는 곳에는 news 를, 전체 주소를 요구하는 곳(예: 카페24)에는 news.example.com 을 넣습니다. 값은 화면에 표시된 값을 그대로 사용하세요. 레코드가 아예 표시되지 않거나 어떤 형식으로 넣어야 할지 확실하지 않다면, 연결하려는 주소와 화면을 함께 문의해 주세요.

블로그 하나에 적용되는 연결 방식은 한 번에 하나뿐이라, blog.example.com 과 news.example.com 을 동시에 운영할 수는 없습니다.

www 주소도 함께 연결하거나, 기존 도메인을 그대로 두고 하나 더 추가할 수 있나요?

아니요. 블로그 하나에는 커스텀 도메인을 하나만 등록할 수 있습니다. 서브도메인·루트 도메인으로 연결한 경우 인블로그는 등록된 그 주소에 대해서만 SSL 인증서를 발급합니다. 등록하지 않은 주소로 들어온 요청은 인블로그가 대신 받아 리디렉션해 드릴 수 없으며, www 를 별도 alias로 함께 등록하는 기능도 없습니다.

www.example.com → example.com 리디렉션이 필요한 경우(과거에 구글이 www 쪽을 대표 주소로 인식해 두었을 때 등)

• www 를 인블로그로 향하는 CNAME 으로만 걸어 두면 ERR_CERT_COMMON_NAME_INVALID 같은 인증서 오류가 납니다. www 는 별개의 호스트명이라 그 이름의 인증서가 없기 때문입니다.

• 인블로그에는 정규 주소 하나만 그대로 등록해 두고, www 는 도메인·호스팅을 관리하시는 쪽(Cloudflare·Vercel·웹서버 등)의 리디렉션 서비스에 연결해 주세요. 그쪽에서 www 용 SSL 인증서를 발급한 뒤 아래처럼 301을 걸면 됩니다.

  https://www.example.com/*  →  https://example.com/*
  

• 경로(path)와 쿼리 파라미터가 유지되도록 설정하시는 편이 좋습니다. 반대 방향(example.com → www.example.com)도 원리는 같습니다.

두 주소를 함께 운영하고 싶은 경우(예: blog.example.com 은 그대로 두고 example.com/guide 를 추가)

• 블로그를 하나 더 만들고, 새 블로그에 두 번째 주소를 연결해 주세요.
• 인블로그의 구독과 도메인 연결은 모두 블로그 단위라, 기존 팀 플랜 구독 하나로 두 블로그를 함께 운영할 수는 없습니다. 새 블로그에는 별도 구독이 필요합니다(결제 · 과금 FAQ 참고).
• 추가할 경로에 이미 기존 페이지가 떠 있다면(예: example.com/guide 에 다른 화면이 열리는 경우) 서브디렉토리로 연결하는 순간 그 경로가 인블로그로 대체됩니다. 기존 페이지를 다른 경로로 옮기거나, 비어 있는 경로를 먼저 정해 주세요.

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

아래 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를 사용해 리버스 프록시 서버 구현

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

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

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

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

'사용 중인 웹 인프라' 목록에 우리 도메인 업체(후이즈·가비아 등)가 없습니다

정상입니다. 이 목록은 도메인을 어디에서 샀는지 고르는 곳이 아니라, 지금 홈페이지가 실제로 서비스되고 있는 환경을 고르는 곳입니다. 화면에도 웹사이트가 배포된 인프라를 선택한 뒤, 아래에 표시되는 가이드대로 설정을 진행해주세요. 라고 안내되어 있습니다. 목록에는 인블로그가 프록시 설정 가이드를 제공하는 환경만 올라옵니다. 후이즈·Namecheap·GoDaddy처럼 도메인 등록·DNS 관리를 주로 맡는 업체는 여기에 없는 것이 맞습니다.

후이즈·가비아·카페24처럼 도메인도 팔고 웹호스팅도 파는 업체라면, 그 업체 이름이 아니라 홈페이지가 실제로 돌아가는 웹서버(대개 Apache 또는 Nginx)를 기준으로 고르세요. Nginx면 Nginx, Apache이거나 확인이 어려우면 기타 / 문의 입니다.

목록에 나오는 항목은 다음과 같습니다.

NextJS · Vercel · AWS Amplify · AWS CloudFront · Cloudflare · Nginx · 웹플로우(Webflow) · 프레이머(Framer) · Cafe24 · Imweb · 기타 / 문의

무엇을 고를지 판단하는 순서

1. 홈페이지 앞단에 Cloudflare나 AWS CloudFront 같은 CDN·프록시가 있다면 → 원 서버 종류와 관계없이 그 CDN을 고릅니다.
2. 앞단 CDN이 없다면 → 홈페이지를 실제로 서비스하는 서버·플랫폼을 고릅니다(Nginx, Vercel, NextJS, 프레이머(Framer) 등).
3. 워드프레스·PHP처럼 목록에 없는 방식으로 만든 사이트라면 → 사이트를 만든 도구가 아니라 그 사이트가 올라가 있는 서버를 기준으로 고릅니다. 워드프레스라도 Nginx 위에서 돌고 있으면 Nginx, Apache 위에서 돌고 있으면 목록에 없으므로 기타 / 문의 입니다.
4. 확인이 어렵다면 → 기타 / 문의 를 고르세요. 채팅 상담으로 연결되며, 연결 가능 여부를 함께 확인해 드립니다.

Cafe24 나 Imweb 을 선택하면 해당 환경에서는 서브디렉토리 연결을 사용할 수 없다는 안내와 함께 루트 도메인 또는 서브도메인 연결을 권하는 문구가 표시됩니다. 다만 카페24는 사용 중인 서비스 종류에 따라 판단이 갈리므로 카페24 항목을 먼저 확인하고, 해당하지 않는다면 서브도메인(blog.example.com) 연결을 사용해 주세요.

홈페이지를 외주로 맡겼다면 제작사에 이렇게 물어보세요

아래 두 가지만 받아 오시면 어떤 항목을 골라야 할지 판단할 수 있습니다.

1. 현재 홈페이지가 어떤 웹서버·호스팅에서 서비스되고 있는지 (예: Nginx, Apache, Vercel, 카페24). 앞단에 Cloudflare·CloudFront 같은 CDN을 쓰는지도 함께 확인해 주세요.
2. /blog 와 /blog/* 경로만 인블로그로 넘기는 리버스 프록시(rewrite) 규칙을 추가할 수 있는지. 리디렉트가 아니라 rewrite여야 합니다.

서브도메인으로 연결하는데도 웹 인프라를 골라야 하나요?

아닙니다. '사용 중인 웹 인프라' 선택 화면은 서브디렉토리 연결에서만 나타납니다.

서브도메인(blog.example.com)과 루트 도메인(example.com) 연결은 기존 홈페이지 서버를 거치지 않고 DNS 레코드만 등록하면 되므로 이 화면 자체가 없습니다. 인프라 목록이 보인다면 지금 서브디렉토리 방식으로 진행 중이라는 뜻입니다.

홈페이지 서버에 프록시 규칙을 넣기 어렵거나 서버를 관리하는 곳이 따로 있어 진행이 막힌다면, 도메인 탭에서 서브도메인 방식으로 바꾸는 편이 훨씬 빠릅니다. 서브도메인은 도메인·DNS를 관리하는 곳(예: 후이즈)에서 레코드만 추가하면 연결됩니다.

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

연결할 호스트가 본인의 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 공식 문서도 Worker Route에 활성 Zone, Worker, Proxied DNS 레코드가 필요하다고 안내합니다. SaaS 호스팅이나 다른 CDN·프록시를 함께 사용하는 경우에는 서비스별 호환성을 별도로 확인해야 합니다.

• Cloudflare Workers Route 요구 사항
• Cloudflare DNS 프록시 사용 사례와 호환성

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

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

• 카페24 웹호스팅의 외부 Cloudflare 연결 정책
• 카페24 매니지드 워드프레스의 Cloudflare 적용 가이드
• 카페24 웹호스팅의 Cloudflare SSL 오류 점검 가이드
• 카페24 쇼핑몰 도메인 연결 가이드

서브디렉토리 대신 서브도메인이나 루트 도메인을 연결할 때는 아래 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)와 쿼리 파라미터도 그대로 유지됩니다. 도메인 인증이 끝나고 팀 플랜(14일 무료 체험 포함)인 상태여야 동작합니다.
• 리디렉션과 함께 캐노니컬 URL도 커스텀 도메인으로 이전되어, 기존에 기본 도메인으로 쌓인 구글 색인이 자연스럽게 커스텀 도메인으로 전환됩니다.
• 서브디렉토리(example.com/blog)로 연결한 경우에는 이 리디렉션이 동작하지 않습니다. 기본 도메인은 계속 200으로 응답합니다. 서브디렉토리는 고객사 서버가 인블로그의 응답을 대신 받아 오는 구조라, 기본 도메인을 그 주소로 돌리면 요청이 서로를 가리키며 무한 루프가 되기 때문에 의도적으로 제외돼 있습니다. 다만 캐노니컬 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)에서 커스텀 도메인으로 보내는 자동 리디렉션은 서브도메인·루트 도메인 연결에서만 동작합니다. 서브디렉토리로 바꾸고 나면 이 리디렉션은 전환 직후뿐 아니라 계속 동작하지 않고, 기본 도메인은 200으로 응답합니다. 대신 캐노니컬이 서브디렉토리 주소를 가리키므로 색인은 그쪽으로 통합됩니다.

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

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

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

도메인을 바꾸면 기존 글 안의 링크와 CTA 버튼 주소도 같이 바뀌나요?

아닙니다. 글 안에 직접 넣은 주소는 그대로 남습니다. 캐노니컬·사이트맵·RSS·카테고리/작성자 페이지 주소는 새 도메인 기준으로 자동 생성되지만, 아래 두 가지는 글에 저장된 값이라 도메인을 바꿔도 따라오지 않습니다.

• 본문에 넣은 절대 주소(https://이전도메인/... 형태의 링크·이미지·버튼)
• 글마다 설정한 하단 CTA 버튼의 URL
• 글에 직접 입력해 둔 캐노니컬 URL. 글별로 캐노니컬을 지정한 적이 있다면 그 값이 자동 생성값보다 우선하므로, 이전 도메인이 그대로 남습니다.

하단 CTA는 일괄로 바꿀 수 있습니다. 게시글 관리에서 대상 글을 선택하면 나타나는 편집을 눌러 일괄 편집 창을 열고, CTA 설정을 켠 뒤 CTA 링크에 새 주소를 넣으면 선택한 글에 한 번에 적용됩니다.

• 다만 일괄 편집은 선택한 글에 같은 값을 덮어쓰는 방식입니다. 글마다 다른 주소를 "이전 도메인 → 새 도메인"으로 찾아 바꾸는 치환 기능은 없으므로, 링크가 서로 다르다면 같은 주소끼리 묶어 나눠 적용해 주세요.
• 본문 링크는 일괄 편집 대상이 아닙니다. 해당 글을 열어 직접 수정해야 합니다.
• 이전 주소에 301 리디렉션을 걸어 두면 방문자는 새 주소로 이동하지만, 글에 남은 링크 자체는 여전히 이전 도메인을 가리킵니다.

글마다 CTA 링크가 달라서 도메인만 바꾸고 싶다면

글이 수백 건이고 CTA 링크가 제각각이라 일괄 편집의 "덮어쓰기"로는 처리할 수 없다면, Posts API로 도메인 부분만 바꿔 넣을 수 있습니다. 별도 기능이 열리기를 기다리실 필요는 없습니다.

1. 대시보드 좌측 메뉴의 설정 → API 키 에서 posts:read 와 posts:write 권한이 포함된 API 키를 발급합니다.

2. GET /api/v1/posts 를 page[number]·page[size] 로 나눠 호출해 각 글의 cta_link 값을 가져옵니다.

3. 값에 이전 도메인이 들어 있는 글만 골라냅니다.

4. 경로·쿼리·해시는 그대로 두고 도메인만 새 도메인으로 바꿉니다.

5. 글마다 PATCH /api/v1/posts/{POST_ID} 로 cta_link 필드만 보냅니다. 요청 본문은 아래 형태입니다.

   { "data": { "type": "posts", "attributes": { "cta_link": "https://새도메인/경로" } } }
   

6. 다시 조회해 이전 도메인이 남아 있지 않은지 확인합니다.

cta_link 만 보내면 본문·제목·발행 상태는 그대로 유지됩니다. 다만 글의 수정일(updated_at)은 갱신되므로, 사이트맵의 lastmod 값도 처리한 글 수만큼 이 날짜로 바뀝니다. 처음에는 글 몇 건에만 적용해 결과를 확인한 뒤 전체로 넓히시는 것을 권장합니다. 자세한 요청 형식은 API 문서를 참고해 주세요.

직접 처리가 어려우시면 블로그 주소와 함께 채팅으로 문의해 주세요.

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

가능합니다.

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

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

상황에 따라 다릅니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

"연결 시작하기"를 눌러도 아무 반응이 없거나, 오류 팝업이 뜨고 다음 화면으로 넘어가지 않습니다

DNS 레코드를 안내받기도 전에 연결을 시작하는 단계 자체가 막히는 경우입니다.

서브디렉토리 탭은 요청이 거부되어도 화면에 오류가 표시되지 않습니다. 주소를 입력하고 연결 시작하기 를 눌렀는데 아무 변화가 없다면 요청이 거부된 것이니 아래 원인을 확인해 주세요. (서브도메인·루트 도메인 탭에서는 오류 팝업이 표시됩니다.)

아래를 순서대로 확인해 주세요.

1. 유료 플랜인지 확인하세요. 커스텀 도메인 연결은 유료 플랜 기능이라, 무료 플랜에서는 연결 요청이 받아들여지지 않습니다.
2. 도메인을 연결할 권한이 있는 계정인지 확인하세요. 해당 블로그의 소유자·관리자·에디터 권한이 있고, 초대 수락까지 끝난 계정이어야 도메인을 연결·해제할 수 있습니다.
3. 짧은 시간에 연결·해제를 여러 번 반복하지 마세요. 도메인 연결·해제 요청은 1시간에 10회로 제한됩니다. 한도를 넘으면 그 뒤의 시도는 모두 거부되어 다음 화면으로 넘어가지 않습니다. 설정이 잘못된 것이 아니므로, 1시간쯤 뒤에 한 번만 다시 시도해 주세요.
4. 입력값 형식을 확인하세요. 서브도메인 탭은 입력란 앞에 https://blog. 가 이미 붙어 있으므로, https:// 와 www 를 빼고 example.com 형태로만 입력합니다. (blog. 가 아닌 다른 서브도메인을 쓰시려면 위 서브도메인 앞의 blog. 를 다른 이름으로 바꿀 수 있나요? 항목을 참고해 루트 도메인 탭을 이용해 주세요.) 서브디렉토리 탭에는 www.example.com/blog 처럼 경로까지 포함한 주소를 입력합니다.
5. (서브디렉토리) 입력한 주소의 도메인이 이미 인터넷에서 조회되는지 확인하세요. 인블로그는 연결을 시작하기 전에 www.example.com/blog 의 도메인 부분(www.example.com)을 공개 DNS에서 조회합니다. 입력한 그 호스트에 공개된 A·AAAA·CNAME 레코드가 하나도 없으면 조회가 실패해 요청이 거부되고, 서브디렉토리 탭이라 화면에는 아무것도 표시되지 않습니다. (www 를 붙여 입력하셨다면 www 가 붙은 주소에 레코드가 있어야 합니다.)

서브디렉토리 연결은 "이미 떠 있는 홈페이지에 블로그를 얹는" 방식입니다. 이 단계에서 확인하는 것은 DNS 레코드의 존재 여부까지이지만, 이후 단계에서는 그 홈페이지에 리버스 프록시 규칙을 직접 설정하셔야 합니다. 기존 홈페이지를 가리키는 DNS 레코드를 먼저 넣어 https://www.example.com 이 정상적으로 열리는 것을 확인한 뒤 연결을 시도해 주세요. Cloudflare를 쓰신다면 해당 레코드가 Proxied 상태여야 합니다.

아직 홈페이지가 없는 새 도메인이라면 서브디렉토리 연결은 적합하지 않습니다. 프록시 규칙을 설정할 홈페이지 자체가 없기 때문입니다. 이때는 blog.example.com 같은 서브도메인 연결을 이용해 주세요. 서브도메인·루트 도메인 연결은 인블로그가 안내하는 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로 인블로그를 서브디렉토리에 연결하려면 아래 설정 항목을 확인해주세요.

1. 메인 웹사이트를 서비스 중인 기존 distribution을 사용하거나, 아직 CloudFront가 설정되어 있지 않다면 새 distribution을 생성하세요.
2. Distribution name은 inblog proxy, Domain은 example.com으로 설정하세요.
3. Origin type은 Other, Custom origin은 proxy.inblog.dev, Origin path는 /{subdomain}으로 설정하세요.
4. CloudFront가 방문자의 Host 헤더를 proxy.inblog.dev로 전달하지 않도록 origin request policy를 Managed-AllViewerExceptHostHeader로 설정하세요.
5. 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;
}

6. /blog, /blog/*, /robots.txt behavior를 추가하세요.
7. 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가 계속된다면 아래 항목을 순서대로 확인해 주세요. 대부분 이 중 하나가 누락된 경우입니다.

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

Apache 웹서버를 쓰고 있는데 서브디렉토리로 연결할 수 있나요?

가능합니다. 대시보드의 인프라 선택 목록에는 Apache가 없으므로 기타 / 문의 를 선택하시고, 아래 예시를 참고해 Apache에 리버스 프록시 규칙을 직접 추가해 주세요. example.com, /blog, {subdomain} 은 실제 값으로 바꿔 주세요.

먼저 어느 서버에 규칙을 넣어야 하는지 부터 확인하세요. 도메인을 구입한 곳(등록대행·네임서버)과 실제로 사이트를 서비스하는 서버가 다른 경우가 많습니다. 네임서버는 국내 호스팅 업체에 있는데 홈페이지는 AWS EC2의 Apache에서 도는 구성이라면, 호스팅 업체의 DNS 화면이 아니라 그 EC2의 Apache 설정 에 프록시 규칙을 넣어야 합니다.

사이트를 서비스하는 VirtualHost(HTTPS를 쓴다면 443 VirtualHost)에 아래 설정을 추가합니다.

SSLProxyEngine On
ProxyPreserveHost Off

ProxyPass "/blog" "https://proxy.inblog.dev/{subdomain}"
ProxyPassReverse "/blog" "https://proxy.inblog.dev/{subdomain}"

ProxyPass "/robots.txt" "https://proxy.inblog.dev/{subdomain}/robots.txt"
ProxyPassReverse "/robots.txt" "https://proxy.inblog.dev/{subdomain}/robots.txt"

• ProxyPass "/blog" 는 /blog 아래 경로까지 함께 전달하므로, 개별 글 주소를 위한 규칙을 따로 추가하지 않아도 됩니다.
• ProxyPreserveHost Off 가 핵심입니다. 방문자의 Host 헤더를 그대로 전달하면 인블로그 쪽에서 요청을 처리하지 못합니다. CloudFront의 Managed-AllViewerExceptHostHeader 정책, Nginx의 proxy_set_header Host proxy.inblog.dev 와 같은 역할입니다.
• 이미 자체 robots.txt를 운영 중이라면 /robots.txt 규칙은 넣지 마세요. 아래 서브디렉토리로 연결하면 기존 robots.txt가 사라지나요? 항목을 참고해 주세요.

필요한 모듈을 켜고 설정을 검사한 뒤 반영합니다.

Ubuntu·Debian 계열

sudo a2enmod proxy proxy_http ssl
sudo apachectl configtest
sudo systemctl reload apache2

Amazon Linux·CentOS·RHEL 계열 (모듈이 이미 켜져 있는 경우가 많습니다)

sudo apachectl configtest
sudo systemctl reload httpd

반영 후 아래 두 주소가 200으로 응답하면 인블로그 도메인 화면의 상태도 자동으로 연결됨 으로 바뀝니다.

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

VirtualHost 파일을 수정할 권한(sudo)이 없다면 서버 운영 담당자에게 위 설정을 요청해 주세요.

서브디렉토리로 연결했는데 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}

rewrite로 설정돼 있고 proxy.inblog.dev 응답도 200인데 루프가 계속된다면, 첫 번째 명령의 응답에서 location 헤더를 확인해 주세요. 되돌려 보내는 주소가 방금 요청한 주소와 같다면 사이트 쪽 설정을 더 손봐도 해결되지 않습니다. 규칙을 계속 바꾸지 마시고 그 응답 헤더 전체를 채팅으로 보내 주세요.

도메인 카드에 도메인 연결 상태 확인 경고가 함께 표시된다면 같은 원인일 수 있습니다. 이 경고는 리디렉트 루프 외에 방화벽 차단이나 일시적 응답 실패로도 표시될 수 있으며, 프록시 규칙이 정상화되면 다음 확인에서 자동으로 해제됩니다. 표시된 문구별 의미는 연결 상태 확인 경고 문구에서 확인해 주세요.

어제까지 잘 되던 블로그가 갑자기 404가 납니다

인블로그 설정을 바꾸지 않았는데 example.com/blog 전체가 404가 되는 경우입니다. 가장 흔한 원인은 사이트 쪽 재배포·CDN·방화벽 변경으로 /blog 프록시 규칙이 사라지거나 덮어써진 것입니다.

먼저: 인블로그의 도메인 연결을 해제하지 마세요. 연결을 지웠다 다시 걸어도 사이트 쪽 프록시 규칙은 복구되지 않고, 소유권 확인 절차만 처음부터 다시 밟게 됩니다.

1. 어떤 404 화면인지부터 확인해 주세요

404 화면의 생김새만으로 요청이 어디까지 도달했는지 구분할 수 있습니다.

2. 어느 쪽이 끊겼는지 명령으로 확인합니다

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

두 번째 명령이 200이면 인블로그 쪽은 정상이므로 사이트의 /blog 규칙만 되살리면 됩니다. 두 번째 명령까지 정상이 아니라면 그 결과를 채팅으로 보내 주세요.

3. 최근에 바뀐 것을 되짚어 주세요

• 사이트 재배포 — 프록시 설정이 배포 산출물에 포함되지 않으면 배포할 때마다 규칙이 사라집니다.
• CDN·WAF 규칙 변경이나 방화벽의 봇 차단 정책 추가
• 웹서버 설정 파일 교체, 인증서 갱신 등 서버 작업

4. 대시보드 경고 문구를 함께 확인해 주세요

설정 → 도메인 화면에 경고가 표시되어 있다면 아래 절에서 문구별 의미를 확인할 수 있습니다.

도메인 카드에 표시되는 '연결 상태 확인 경고'는 무슨 뜻인가요?

인블로그는 연결된 도메인이 실제로 이 블로그를 서빙하는지 주기적으로 확인하고, 예상한 응답을 받지 못하면 설정 → 도메인 화면에 도메인 연결 상태 확인 경고를 표시합니다.

경고가 떴다고 해서 블로그 접속이 바로 막히는 것은 아니며, 다음 확인에서 정상 응답이 오면 자동으로 해제됩니다. 문구마다 확인할 곳이 다릅니다.

서브디렉토리로 연결하면 기존 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-09-07