连接自定义域名

使用子域名（例如 blog.example.com）、根域名或子目录（例如 example.com/blog）连接基于 inblog 构建的博客，并提供 DNS 配置指南。

概述

域名设置部分可能需要开发人员协助，尤其是 DNS 配置或代码实现环节。如有需要，我们可提供技术支持会话。

你可以通过以下三种方式之一连接基于 inblog 构建的博客：

• 子域名（例如 blog.example.com）
• 根域名（例如 example.com）
• 子目录（例如 example.com/blog）

在哪里添加 DNS 记录： DNS 设置必须在管理你域名的地方（例如 Namecheap、GoDaddy、Cloudflare）添加，而不是在你构建网站的地方（例如 Webflow、Framer）。如果你在 Webflow 上构建了网站，但通过 GoDaddy 购买了域名，请在 GoDaddy 中添加 DNS 记录。

在哪里找到域名设置

1. 在 inblog.ai/dashboard 登录。你将进入你的博客列表。
2. 点击你要设置的博客卡片。域名是按博客分别配置的，因此如果你管理多个博客，请确认选中了正确的博客。
3. 在左侧菜单中，点击 设置 分组标题下的 域名。（无需先打开 设置 界面再在里面寻找——直接点击左侧菜单中的 域名 即可。）
4. 在“域名”界面的顶部，选择 子目录、子域名 或 根域名 选项卡，输入你的地址，然后点击 开始连接。在“子目录”选项卡上，你接下来需要选择所使用的 Web 基础设施，随后会出现对应的逐步反向代理指南。

如果“域名”界面呈灰色且无法输入，说明该博客使用的是免费套餐。自定义域名功能适用于 Team 套餐（包括 14 天免费试用）。

如果点击卡片后打开的是初始设置界面而非管理界面，请在其中完成域名设置步骤。有关详细信息，请参阅快速上手 inblog中的初始设置部分。

子域名设置

在自定义域名设置中，选择子域名并输入你的域名——无需输入子域名部分。该字段带有固定的 https://blog. 前缀，因此在此处输入 example.com 将始终连接到 blog.example.com。

一个博客一次只能使用一种连接方式，因此无法同时运行 blog.example.com 和 news.example.com。

点击开始连接获取 DNS 配置说明。在你的 DNS 服务商处完全按照显示的内容添加记录。DNS 更改最多可能需要 24 小时才能生效传播，inblog 会自动检查连接状态。

如果域名由其他人管理，请使用 DNS 记录下方的复制请求消息，并将该消息发送给你的开发人员或域名管理员。其中包含他们需要添加的地址和每条记录。

如果你的 DNS 服务商拒绝了 CNAME 值： 某些服务商（例如 Gabia）要求该值为完全限定域名（FQDN），并显示诸如“值必须以点（.）结尾”之类的错误。在这种情况下，请在 inblog 提供的确切值末尾添加一个点。例如，如果 inblog 显示 abc123.vercel-dns-016.com，请输入 abc123.vercel-dns-016.com.。其他服务商（例如 Imweb）则要求不带末尾的点。请遵循你的服务商所要求的格式。

我还可以同时连接 www，或添加第二个域名吗？

不可以。一个博客只能绑定一个自定义域名。 对于子域名和根域名连接，inblog 仅为你注册的地址签发 SSL 证书。它无法接收并重定向未注册地址的请求，并且也没有用于 www 的独立别名字段。

如果你需要将 www.example.com → 重定向至 example.com（例如，因为 Google 已经将 www 版本视为规范网址）：

• 仅使用 CNAME 将 www 指向 inblog 会导致证书错误，例如 ERR_CERT_COMMON_NAME_INVALID——www 是一个独立的主机名，不存在对应的证书。

• 请仅在 inblog 中注册你的规范地址，并将 www 指向管理你域名或托管服务方的重定向服务（Cloudflare、Vercel、你的 Web 服务器）。在该处签发 www 证书，然后添加如下所示的永久重定向。对于新规则，我们建议使用 308；若已有正常工作的 301 规则可继续保留，或者当你的服务商仅支持 301 时使用 301。请参阅 308 与 301 的区别以及何时使用：

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

• 在规则中保留路径和查询字符串。反向重定向（example.com → www.example.com）的工作方式相同。

如果你想同时运行两个地址（例如保留 blog.example.com 并添加 example.com/guide）：

• 创建第二个博客并将第二个地址连接到该博客。
• 在 inblog 中，订阅和域名连接均按博客划分，因此一个 Team 套餐订阅无法覆盖两个博客。新博客需要拥有自己的订阅——请参阅常见问题解答 (FAQ)。
• 如果你要添加的路径下已存在页面（假设 example.com/guide 目前会打开其他内容），将其作为子目录连接将用 inblog 替换该路径。请将现有页面移至别处，或选择一个空闲路径。

子目录（Sub-folder）设置

仪表盘目前提供 Next.js、Vercel、AWS Amplify、AWS CloudFront、Cloudflare、Nginx、Webflow 和 Framer 的设置指南。如果列表中没有你的基础设施，请选择其他 / 咨询。

支持的平台包括：

• Next.js：支持，但静态导出（static export）除外
• Vercel / AWS Amplify：作为托管平台受支持
• Cloudflare：当可以在你自己的 Cloudflare 账户中管理主机名的 Zone、Worker 和 Routes，且现有网站在其 DNS 记录处于 Proxied（已代理）状态下仍可正常运行时受支持。仅在响应头或 IP 查询中看到 Cloudflare 并不满足此要求。
• Framer / Webflow：通过使用 Cloudflare 的反向代理受支持

在使用 Cloudflare 指南之前： 仅当现有网站在处于 Proxied 状态下已能正常工作，且目标路径（例如 /blog）未使用，或者其现有内容和 URL 已完成迁移时，方可继续操作。若记录为 DNS only（仅限 DNS）、使用 SaaS 网站构建工具、使用其他 CDN 或代理，或者账户无法管理 Cloudflare Zone 和 Worker Routes，则需要另行评估。如果该主机名无法保持代理状态，请改用子域名连接。

仪表盘的连接指南还提供了 AWS CloudFront 和 Nginx 的逐步设置说明。

如果你的环境不在该列表中（例如 Apache），请选择其他 / 咨询。任何能够将特定路径代理到外部源站的 Web 服务器都可以通过自定义反向代理进行连接——欢迎通过在线客服与我们联系，我们将与你确认可行性。

在自定义域名设置中选择子目录，并输入你的域名（例如 example.com/blog）。点击开始连接获取完整设置指南。请注意，子目录设置通常需要进行代码实现。

“Web 基础设施”选择器不会改变 inblog 端的任何设置。 它仅决定你看到的设置指南，因此日后切换它对你已连接的域名没有任何影响。

如果在你的 Web 服务器（Apache、Nginx 等）前面已经存在 CDN 或代理（例如 Cloudflare 或 CloudFront），请选择该 CDN，无论源服务器是什么。在请求最先到达的地方处理代理规则更加简便，并且不会改动你的源站配置。

我的域名注册商不在“Web 基础设施”列表中

这是正常现象。该列表询问的是你网站当前的托管服务位置，而不是你购买域名的位置。 屏幕上提示：“选择托管你的网站的基础设施，然后按照下方的匹配指南操作。”它仅列出了 inblog 提供代理指南的环境，因此 Namecheap 或 GoDaddy 等注册商和 DNS 服务商不属于这里的选项。

如果你的服务商同时销售域名和虚拟主机/服务器托管（Gabia、Cafe24 等），请根据你的网站实际运行的 Web 服务器（通常是 Apache 或 Nginx）来选择，而不是看服务商的名称。Nginx 选择 Nginx；Apache 或任何你无法确认的环境，选择 其他 / 咨询。

该列表包含：NextJS、Vercel、AWS Amplify、AWS CloudFront、Cloudflare、Nginx、Webflow、Framer 和 其他 / 咨询。（韩语仪表盘还会显示 Cafe24 和 Imweb；选择这两者会提示该环境不可使用子目录连接。）

如何决定：

1. 如果你的网站前端有 CDN 或代理（例如 Cloudflare 或 AWS CloudFront），无论源服务器是什么，都请选择该 CDN。
2. 否则，请选择实际托管该网站的服务器或平台（Nginx、Vercel、NextJS、Framer 等）。
3. 如果网站是用未列出的工具构建的（WordPress、PHP），请根据其运行的服务器来选择，而不是构建它的工具。运行在 Nginx 上的 WordPress 选择 Nginx；运行在 Apache 上的 WordPress 未列出，因此请选择 其他 / 咨询。
4. 如果你无法确定，请选择 其他 / 咨询——这会开启与我们的在线客服会话，我们将与你一起确认可行性。

如果你的网站是由外包公司构建的，请向他们询问两件事

1. 目前托管该网站的 Web 服务器或托管服务是什么（Nginx、Apache、Vercel 等），以及前面是否部署了 CDN（例如 Cloudflare 或 CloudFront）。
2. 他们是否可以仅为 /blog 和 /blog/* 添加一条反向代理（重写/rewrite）规则。该规则必须是 rewrite（重写），而不是 redirect（重定向）。

子域名连接需要选择 Web 基础设施吗？

不需要。Web 基础设施选择器仅在子目录连接时出现。

子域名（blog.example.com）和根域名（example.com）连接完全不会接触你现有网站的服务器——你只需添加 DNS 记录即可——因此根本不会出现该界面。如果你看到了基础设施列表，说明你目前正在进行子目录连接流程。

如果你无法在网站服务器上添加代理规则，在“域名”选项卡中切换为子域名连接通常是更快捷的方法：它只需要在管理你域名的服务商处添加 DNS 记录即可。

AWS CloudFront 子目录设置

如需使用 AWS CloudFront 将 inblog 配置在子目录下，请查看以下设置步骤。

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. 将 origin request policy 设置为 Managed-AllViewerExceptHostHeader，以便 CloudFront 不会将访问者的 Host 标头转发给 proxy.inblog.dev。
5. 创建一个用于 URI 重写的 CloudFront Function 并粘贴以下代码。

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

  var host = request.headers.host && request.headers.host.value;
  if (host) {
    request.headers["x-inblog-public-host"] = { value: host };
    request.headers["x-forwarded-host"] = { value: host };
  }
  request.headers["x-forwarded-prefix"] = { value: basePath };

  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. 将函数发布（Publish）为 Live，然后将其关联到全部三个 behavior 的 Viewer request 事件。

部署完成后，请在终端中验证以下 URL。

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

CloudFront 返回 502 错误

首先，确保你没有将 Origin path 留空。子目录连接使用的是 Custom origin proxy.inblog.dev 以及 Origin path /{subdomain}——而不是单独的 CNAME 值。

如果你的设置与此一致但仍持续出现 502 错误，请按顺序检查以下项目。大多数情况下都是遗漏了其中一项。

1. 全部三个 behavior（/blog、/blog/* 和 /robots.txt）均使用 proxy.inblog.dev 源站。
2. 全部三个 behavior 均使用 Managed-AllViewerExceptHostHeader 源请求策略（origin request policy）。如果转发了访问者的 Host 标头，源站将无法处理该请求。
3. CloudFront Function 已发布为 Live——仅保存是不够的。
4. 该函数已关联到全部三个 behavior 的 Viewer request 事件。
5. Distribution 已完成部署（Deployed），包括你最近所做的更改。

如果上述所有项目均确认无误但 502 错误依旧存在，请将以下三条命令的输出发送给我们。将通过 CloudFront 的请求与直接向源站发送的请求进行对比，有助于我们定位原因。

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 中，则代理规则应写入该 EC2 实例的 Apache 配置中，而不是托管服务商的 DNS 界面中。

将以下内容添加到托管你网站的 VirtualHost 中（如果你使用 HTTPS，则为 443 端口的 VirtualHost）。

SSLProxyEngine On
ProxyPreserveHost Off

<Location "/blog">
  RequestHeader set X-Inblog-Public-Host "expr=%{HTTP_HOST}"
  RequestHeader set X-Forwarded-Host "expr=%{HTTP_HOST}"
  RequestHeader set X-Forwarded-Prefix "/blog"
</Location>

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 下的所有内容，因此你无需为单独的文章 URL 配置独立规则。
• <Location "/blog"> 内的两行 RequestHeader 告知 inblog 访问者实际浏览的地址（example.com）及其所在的子目录（/blog）。代理会剥离这两者，而分析统计需要它们来正确归属文章 URL。路由本身从不读取它们，因此即使不包含它们，博客也能继续工作（它们需要 mod_headers 模块）。请保留在 <Location> 块内部：如果放在 VirtualHost 作用域内，它们将被附加到你网站的每一个请求中，可能会改变你的应用程序构建其 URL 的方式。
• ProxyPreserveHost Off 是关键行。如果访问者的 Host 标头原样转发，inblog 将无法处理该请求。它的作用与 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 headers
sudo apachectl configtest
sudo systemctl reload apache2

Amazon Linux / CentOS / RHEL（这些模块通常已默认启用）

sudo apachectl configtest
sudo systemctl reload httpd

一旦下方两个 URL 均返回 200，inblog 域名界面上的状态就会自动切换为 已连接。

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

如果你没有编辑 VirtualHost 文件的权限（sudo），请让服务器运维人员应用上述配置。

我的子目录博客返回 ERR_TOO_MANY_REDIRECTS

博客路径陷入了重定向循环，完全无法加载。原因通常是你自己网站上的 /blog 规则。以下是两种最常见的情况。

1. 必须是 rewrite，而不是 redirect

将 /blog 传递给 inblog 需要使用 rewrite（反向代理）——地址保持不变，你的服务器返回 inblog 的响应。而 redirect 会使 /blog 请求重新指向 /blog，从而导致无限循环。

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

2. inblog 与你网站规范地址之间的 www 形式不一致

如果你的网站将 example.com（非 www）视为规范地址，但在 inblog 上注册的地址是 www.example.com/blog，则 www 与非 www 之间的重定向会来回弹跳。请统一步调，使用同一种形式。

• 在 inblog 的域名选项卡上注册地址时，使用的形式应与你网站作为规范地址的形式保持一致。
• 在主机的域名重定向设置中，仅单向应用 www → 非 www 合并——而不要将其配置为针对 /blog 的特定规则。

如何判断是哪一方的问题

比较每个地址的响应标头。如果最后一条命令返回 200，通常是你网站的重定向规则需要修复——请注意下面提到的特例。如果它返回 3xx，则需要检查 inblog 端——请通过在线客服将该输出发送给我们。

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

inblog 没有任何变动，但整个 example.com/blog 都返回 404。最常见的原因是你网站上的重新部署、CDN 更改或防火墙调整导致 /blog 代理规则丢失或被覆盖。

首先：不要在 inblog 中断开域名连接。 移除并重新添加连接不会恢复你网站的代理规则——这只会迫使你重新进行域名验证。

1. 确认你看到的是哪个 404 页面

404 页面的外观可以告诉你请求到达了哪一步。

2. 通过发起请求排查故障方

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

如果第二条命令返回 200，说明 inblog 正常，你只需恢复网站上的 /blog 规则即可。如果第二条命令也失败，请通过在线客服将该输出发送给我们。

3. 回溯近期发生的变化

• 网站重新部署——如果代理配置不属于构建输出的一部分，每次部署都会抹掉该规则。
• CDN 或 WAF 规则变更，或者新添加的防爬虫/Bot 防护策略。
• Web 服务器配置替换、证书更新或类似的服务器维护工作。

4. 同时检查仪表盘警告

如果设置 → 域名显示警告，下一节将解释每条消息的含义。

域名卡片上的“连接检查警告”是什么意思？

inblog 会定期检查你连接的域名是否确实在为该博客提供服务，并在未收到预期响应时在设置 → 域名下显示域名连接检查警告。

仅该警告本身并不会阻止访客访问你的博客，并且一旦后续检查成功，它就会自动清除。不同的消息指向不同的原因。

子目录设置会覆盖我现有的 robots.txt 吗？

设置指南中包含一条规则，在代理博客路径（/blog、/blog/*）的同时将 /robots.txt 代理至 inblog。该规则是为尚无 robots.txt 的网站准备的。如果你已经维护了自己的 robots.txt，请不要原样应用该规则。

一个域名只能有一个 robots.txt，它在根路径下提供服务，并适用于其下的所有路径。代理 /robots.txt 意味着将返回 inblog 的文件而不是你的文件，因此你原有的所有 Disallow 规则都将失效。

如果你已经拥有 robots.txt，请选择以下方式之一：

1. 仅移除 /robots.txt 规则（推荐）

• 保留博客路径（/blog、/blog/*）的代理规则，仅删除 /robots.txt 规则。
• 在你现有的 robots.txt 中添加博客的网站地图：

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

• 确认你现有的任何 Disallow 规则都不会屏蔽博客路径（/blog）。

2. 保留代理并在 inblog 内编辑 robots.txt

• 前往仪表盘中的设置 → SEO 工具 → Robots.txt（在付费套餐且已连接自定义域名后可用）。
• 将你现有的规则粘贴到此处，并保留博客网站地图行。无论你在此处保存什么内容，都将作为 example.com/robots.txt 的响应提供。
• 编辑器预填充了 inblog 生成的默认内容（允许所有爬虫，外加网站地图 URL）。完全清空并保存即可恢复为该默认设置。

你无需自行维护网站地图。 配置好代理后，每当你发布或编辑文章时，inblog 都会自动重新生成 example.com/blog/sitemap.xml。你这边无需上传或刷新任何 xml 文件。

子目录与 Google Search Console

当你连接子目录（例如 example.com/blog）时，你的博客流量会被包含在现有的根域名 Search Console 资源中。如果你希望单独分析仅博客部分的数据，可以添加一个额外的仅此博客地址资源：

• 资源类型：URL prefix
• URL：https://example.com/blog

这个独立资源同样需要进行自己的 HTML 标签验证。请在 inblog 仪表盘的“设计”选项卡 →“高级设置”（代码注入）中，为该资源添加对应的 meta 标签。

点击“开始连接”毫无反应，或弹出错误窗口阻止进入下一步

这是在添加 DNS 记录之前的步骤——连接本身未能启动。

如果请求被拒绝，“域名”界面会在地址字段旁或弹窗中显示错误。在重试之前，请检查以下原因。

请按顺序检查以下项目：

1. 确认你使用的是付费套餐。 连接自定义域名是付费套餐功能，因此在免费套餐上连接请求会被拒绝。
2. 确认你的账户有权限连接域名。 只有该博客的所有者（owner）、管理员（admin）或编辑（editor）——且已接受邀请——才可以连接或断开域名。
3. 不要在短时间内频繁连接和断开连接。 域名连接/断开请求限制为每小时 10 次。超出该限制后，后续的所有尝试都会被拒绝且无法推进。这并不代表配置有误——只需等待大约一小时后再试一次即可。
4. 检查输入格式。 子域名选项卡已在字段前加上了 https://blog.，因此只需输入 example.com——不要带 https:// 或 www。子目录选项卡则需要完整路径，例如 www.example.com/blog。
5. （子目录）确认你输入的域名在互联网上已经可以解析。 在启动连接之前，inblog 会在公共 DNS 中查找 www.example.com/blog 的域名部分（www.example.com）。如果该确切主机没有公共 A、AAAA 或 CNAME 记录，查找就会失败，请求也会被拒绝。（如果你输入了 www，则记录必须存在于 www 主机上。）

子目录连接是将你的博客叠加到已经上线的网站上。 此步骤仅检查 DNS 记录是否存在，但后续步骤需要你在该网站上添加反向代理规则。请先添加指向现有网站的 DNS 记录，确认 https://www.example.com 能正常打开，然后再开始连接。在 Cloudflare 上，该记录必须处于 Proxied 状态。

如果这是一个全新域名且背后尚未搭建网站，则子目录连接并不适合——因为没有现成网站可以放置代理规则。此时请改用子域名（如 blog.example.com）；子域名和根域名连接只需添加 inblog 提供的 DNS 记录即可，因此不需要已有网站。

博客列表中的 （未验证） 是什么意思？

添加 DNS 记录后，inblog 仪表盘的博客列表中的域名状态可能会显示为 （未验证）。这意味着 inblog 尚未确认你的 DNS 记录。常见原因：

• DNS 记录尚未添加，或填写的数值不正确。
• 做出更改后，DNS 传播最多需要 24–48 小时。

一旦状态变为 （已验证），即表示 DNS 确认完毕。域名可能还需要几分钟时间才能完全正常访问。

“域名”选项卡显示“正在签发 SSL 证书”。我只需要等待吗？

大多数情况下，是的。 除非你在域名上设置了 CAA 记录，否则无需进行其他操作。“正在签发 SSL 证书”仅在你的 DNS 记录确认通过之后才会出现，此时 HTTPS 设置是最后的剩余步骤。这表明你的记录已经通过了验证。

对于子域名和根域名连接，“域名”选项卡会显示以下四种连接状态之一：

子目录连接则会显示另一组由三种状态构成的流程：需要设置反向代理、正在检查反向代理连接 和 已连接。

DNS 更改最多可能需要 24–48 小时才能传播完毕，证书签发后，网站可能还需要几分钟才能打开。

• 如果你在域名上设置了 CAA 记录，也请检查该记录——它可能会阻止证书签发。
• 如果在“正在签发 SSL 证书”状态停留超过一天，请将你正在连接的地址以及截图发送给我们。

域名卡片显示“Could not find nameservers for this domain.”

inblog 会查找你所输入地址背后的根域名的域名服务器（例如 blog.example.com → example.com），以便告知你应在哪个 DNS 服务中添加记录。该警告意味着该查询没有返回任何结果。请检查以下事项：

• 域名拼写正确。
• 域名确实已注册且未过期。
• 已在你的域名注册商处分配了域名服务器（购买后立即查看可能为空）。

该警告仅反映我们用于告知你应使用哪个 DNS 服务的查询结果——并不会阻碍验证。如果域名确实未分配任何域名服务器，你添加的记录也将无法解析，因此请先在注册商处完成域名服务器设置。如果在添加记录后连接正常进行，你可以忽略此警告。

我自己能打开，但其他人打不开我的博客

有时域名状态显示为 “已验证” 且你这边博客加载正常，但你分享链接的人却无法访问。这通常不是域名配置问题——他们所在的网络（家庭 Wi-Fi、移动运营商、办公室网络）在其 DNS 缓存中仍保留着旧状态。DNS 更改在不同网络上的生效速度不同，最长可持续 24–48 小时，因此公共 DNS 可能已经正确，但某些网络仍无法解析该地址。

应对措施：

• 分享完整地址（例如 https://blog.example.com），而不是部分地址。
• 让无法访问的人尝试使用移动数据网络代替 Wi-Fi，或稍后再试。
• 如果在 24–48 小时后特定网络仍无法访问，请将使用的确切地址以及该环境下的错误截图发送给我们。

我可以把子域名博客迁移到子目录吗？

可以。在“域名”选项卡上将连接类型切换为子目录并注册新地址（例如 example.com/blog）。请注意，一个博客一次只能使用一种连接类型，因此 blog.example.com 和 example.com/blog 无法并行运行。

会自动处理的事项

• 文章别名（slug）不会改变。仅主机和前置路径有所不同，因此无需对每篇文章逐一处理。
• 一旦新连接通过验证，规范网址（canonical URL）、网站地图、RSS 以及分类/作者页面地址都会切换到新地址（缓存可能需要几分钟才能同步更新）。
• API 和 CLI 自动化（Make、Zapier、n8n 等）不受影响。 API 密钥绑定在博客本身而非自定义域名上，因此更改连接类型不会使其失效。

你需要自行处理的事项

• 自行配置从旧自定义子域名（blog.example.com）发起的永久重定向（建议使用 308）。 一旦断开连接，inblog 将不再响应该主机，因此请在管理域名或托管服务的平台中添加 blog.example.com/{slug} → example.com/blog/{slug} 规则。由于 slug 未变，只需一条替换主机并添加 /blog 前缀的规则即可。
• 首先将 blog.example.com 的 DNS 记录从 inblog 移开，否则重定向规则不会生效——如果旧 CNAME 仍然存在，请求将继续发送给 inblog。
• 默认的 inblog 域名（xxx.inblog.io）与你的旧自定义域名具有不同的重定向行为。对于子域名和根域名连接，当域名已验证且博客拥有符合条件的 Team 或更高级别套餐（或有效试用期）时，默认域名会自动重定向。对于子目录连接，默认域名的重定向取决于代理设置：使用默认域名作为源站的代理如果发生回跳，可能会陷入重定向循环。在依赖该重定向之前，请通过在线客服联系我们以检查你的配置。规范网址会单独将子目录地址标示为首选 URL。你的团队仍必须配置来自旧自定义域名的重定向。

切换期间博客会宕机吗？

在验证新的代理设置后，请检查博客是否能在新的子目录地址下正常加载。此外，请分别检查默认域名的重定向行为和旧自定义域名的重定向规则。除了添加 /blog 路径规则之外，你现有的网站不会受到任何改动。

搜索引擎需要时间重新索引更改后的地址。请设置从每个旧地址到其对应新页面的永久重定向。对于新规则，我们建议使用 308，但无需更改现有的正常工作的 301 规则。重定向能指示新地址；但它们并不能保证收录、排名或流量。

更改域名后，文章内的链接和 CTA 按钮也会更新吗？

不会——写在文章中的地址会保持原样。 规范网址、网站地图、RSS 以及分类/作者页面会针对新域名重新生成，但以下两项保存在文章本身中，不会随之自动更新：

• 正文中的绝对地址（指向 https://old-domain/... 的链接、图片或按钮）
• 每篇文章底部 CTA 按钮上的 URL
• 你自行在文章中输入的规范网址（canonical URL）。 文章独立的规范网址优先级高于自动生成的网址，因此它会继续指向旧域名。

底部 CTA 可以批量修改。 在文章管理中，选择文章并点击编辑打开批量编辑对话框，然后开启 CTA 设置，并在 CTA 链接 下输入新地址，即可一次性应用到所有选中的文章。

• 批量编辑会将相同的值覆盖到所选文章中。它没有按文章逐个执行“旧域名 → 新域名”的查找替换功能，因此如果各文章链接不同，请将共用同一地址的文章分组并分批应用。
• 正文内的链接不在批量编辑覆盖范围内。 请打开文章并在其中进行编辑。
• 旧地址上的永久重定向会将访客带到新地址，但保存在文章内的链接仍将指向旧域名。

当每篇文章的 CTA 链接都不同且你只想替换域名时

如果你有数百篇文章且各自的 CTA 链接都不相同，导致批量编辑的“全局相同值”无法满足需求，你可以通过 Posts API 仅替换域名。 无需等待专属功能的推出。

1. 在左侧菜单的 设置 → API 密钥 下，签发一个包含 posts:read 和 posts:write 权限作用域的 API 密钥。

2. 使用 page[number] 和 page[size] 逐页调用 GET /api/v1/posts，以读取每篇文章的 cta_link。

3. 仅保留其值包含旧域名的文章。

4. 保持路径、查询参数和哈希锚点不变，仅将域名替换为新域名。

5. 对每篇文章发送带有 cta_link 字段的 PATCH /api/v1/posts/{POST_ID}。请求体如下所示：

   { "data": { "type": "posts", "attributes": { "cta_link": "https://new-domain/path" } } }
   

6. 重新读取文章，确认没有残留的旧域名。

仅发送 cta_link 不会影响正文、标题和发布状态。请注意，这确实会更新每篇文章的 updated_at，因此你处理的每篇文章在网站地图中的 lastmod 值都会变为该日期。我们建议先在几篇文章上试运行并在确认结果后再全量执行。有关确切的请求格式，请参阅 API 文档。

如果你无法自行执行该操作，请通过在线客服联系我们并提供你的博客地址。

没有域名？没关系。

如果你没有自定义域名，可以在设置过程中选择“I don't own a domain”选项，继续使用默认的博客域名（例如 example.inblog.io）。你可以随时升级到自定义域名。

如何在主网站导航中添加“博客”选项卡？

inblog 无法控制你主网站的导航菜单。要添加博客链接，请在构建主网站所用的工具（例如 Webflow、Framer、WordPress 或你的 CMS）中更新导航。

将你的 inblog 博客地址用作链接目标：

• 子域名：https://blog.example.com
• 子目录：https://example.com/blog

在连接自定义域名之前，你可以临时使用默认的 inblog 域名，例如 https://example.inblog.io。

如何让博客顶部的 Logo 链接回我的主网站？

在 inblog 仪表盘中，前往设计选项卡 → Header。在该处你可以设置 Logo 图片以及访客点击时跳转的 URL。输入你的主网站 URL 即可让访客重定向到你的主页。

最后更新 2026-10-14