域名系统

Google Public DNS 是由 Google 运营的免费全球分布式域名系统解析器，主要地址为 8.8.8.8，备用地址为 8.8.4.4。将您的 ISP 默认 DNS 服务器替换为这些地址，可以降低 DNS 查询延迟、增强解析器对缓存投毒攻击的防御能力，并消除因区域性 ISP 故障导致的单点故障。 本指南涵盖 Windows、macOS、Linux 及网络路由器上的完整配置流程，包括永久持久化技术、IPv6 地址、验证命令，以及大多数教程所忽略的常见陷阱。 Google Public DNS 的实际作用 当您在浏览器中输入域名时，操作系统会向 DNS 解析器发送查询请求。该解析器将人类可读的主机名转换为可路由的 IP 地址。默认情况下，此解析器由您的 ISP 通过 DHCP 分配——而 ISP 解析器通常速度较慢、安全性较低，有时还会被用于流量拦截或广告注入。 Google Public DNS 运营着一个覆盖全球多个接入点的 anycast 网络。每个查询由最近的可用节点响应，从而最大限度地减少往返时间。Google 还实现了 DNSSEC 验证、DNS-over-HTTPS (DoH) 和 DNS-over-TLS (DoT)——这些协议对 DNS 查询通道进行加密，防止路径上的攻击者读取或篡改您的查询。 Google Public DNS 地址（IPv4 和 […]

电子邮件至今仍是企业和个人数字通信的核心支柱，然而大多数用户对其底层运作机制知之甚少。从本质上看，电子邮件投递是一个多阶段的中继过程，由一套精确的协议链条来管理——SMTP负责传输，DNS MX记录负责路由，IMAP或POP3负责接收——各环节依次执行，在数秒内将邮件从发件人客户端送达收件人收件箱。 理解这一架构绝非纯粹的学术探讨。系统管理员、开发人员以及所有负责邮件环境管理的人员，都必须掌握这些组件之间的交互方式，才能诊断投递故障、强化安全防护、正确配置服务器，并避免邮件被归入垃圾邮件文件夹。本指南涵盖完整的技术全貌，包括入门文章中普遍忽略的边缘情况与故障模式。 电子邮件基础设施的关键组件 在追踪单封邮件的完整生命周期之前，有必要先厘清所涉及的各个独立系统。每个系统都承担着不可或缺的角色，任何一个环节的配置错误都可能悄无声息地导致投递失败。 邮件客户端（MUA — 邮件用户代理） 邮件用户代理（MUA）是用户撰写、发送和阅读邮件的界面。常见示例包括Microsoft Outlook、Apple Mail、Mozilla Thunderbird，以及Gmail网页界面等基于浏览器的客户端。MUA并不直接将邮件投递给收件人，其职责是将邮件移交给邮件提交代理（MSA）——通常在端口587上运行并要求身份验证——再由MSA传递给出站SMTP服务器。 一个常见的架构误解是将MUA与SMTP服务器视为一个整体。事实并非如此。MUA是客户端，SMTP基础设施才是传输层。 邮件服务器（MTA — 邮件传输代理） 邮件传输代理（MTA）是负责在系统之间中继邮件的服务器软件。Postfix、Exim、Sendmail和Microsoft Exchange是部署最广泛的MTA。MTA可以根据事务方向，同时充当发送方和接收方。正是MTA执行DNS查询、与远程服务器建立SMTP连接，并在投递失败时将邮件加入队列以便重试。 邮件投递代理（MDA） 在简化说明中常被忽视的邮件投递代理（MDA），是负责将接收MTA已接受的邮件放入磁盘上正确用户邮箱的组件。Dovecot和Courier是常见的MDA。MDA负责执行邮箱配额限制、应用服务器端过滤规则（Sieve脚本），并将邮件写入相应的存储格式（Maildir或mbox）。 DNS与MX记录 域名系统是电子邮件的路由骨干。若没有有效的MX（邮件交换）记录，任何外部服务器都无法找到特定域名的邮件投递目标。MX记录包含优先级值——数字越小优先级越高——允许管理员配置主邮件服务器和备用邮件服务器。发送MTA查询MX记录后，在发起连接之前，还需通过A记录或AAAA记录将所得主机名解析为IP地址。 电子邮件投递流程：逐步详解 第一步：邮件撰写与提交 用户在MUA中撰写邮件，填写收件人地址、主题、正文内容及附件。附件和HTML内容使用MIME（多用途互联网邮件扩展）进行编码，将二进制数据包装为base64编码格式，以便在基于文本的SMTP上安全传输。例如，包含PDF附件的邮件会被拆分为多个MIME部分：一部分用于文本正文，另一部分用于编码后的二进制数据。 用户点击”发送”后，MUA会向出站邮件服务器建立经过身份验证的加密连接——通常使用端口587（STARTTLS）或端口465（SMTPS）。通过SASL（简单身份验证和安全层）进行身份验证，可防止未经授权的中继滥用。 第二步：SMTP握手与邮件传输 发送MTA通过正式握手发起SMTP会话： 客户端发送`EHLO`（扩展HELO），以主机名标识自身。 服务器响应其支持的功能（例如STARTTLS、AUTH、SIZE限制）。 客户端发出`MAIL FROM:<sender@domain.com>`以声明信封发件人。 客户端发出`RCPT TO:<recipient@domain.com>`以声明收件人。 客户端发送`DATA`，随后附上完整的邮件头部和正文。 会话以`QUIT`结束。 无论连接发生在客户端与提交服务器之间，还是两个MTA在互联网上中继邮件之间，这一SMTP对话流程完全相同。 第三步：DNS解析与MX查询 发送MTA在连接收件人服务器之前，必须先解析目标地址。该过程遵循严格的顺序： 查询DNS以获取收件人域名的MX记录（例如`example.com`）。 接收一条或多条MX记录，每条记录包含主机名和优先级值。 通过A记录（IPv4）或AAAA记录（IPv6）将MX主机名解析为IP地址。 优先尝试连接优先级最高（数字最小）的MX主机。 关键边缘情况：若某域名不存在MX记录，RFC 5321规定发送MTA应回退至该域名的A记录并尝试直接投递。这一行为常被配置错误的域名所利用，可能导致意外的投递路径。此外，若MX记录指向CNAME，则违反RFC 2181，可能导致严格MTA出现投递失败。 第四步：服务器间SMTP中继 IP地址解析完成后，发送MTA通过端口25与收件人MTA建立TCP连接。端口25专用于服务器间通信，ISP通常会对住宅连接封锁该端口，以防止垃圾邮件从消费者IP段发出。 在企业和云环境中，邮件在到达目的地之前可能经过多个中继跳转。每次中继都会在邮件中添加一个`Received:`头部，形成可追溯的审计记录。检查这些头部是诊断投递延迟、识别邮件被滞留或拒绝位置的主要方法。 若两端服务器均支持，此阶段将协商STARTTLS机会性加密。若接收服务器未通告STARTTLS，大多数MTA会回退至未加密传输而非拒绝投递——这是一个已知的安全弱点，MTA-STS（邮件传输代理严格传输安全）正是为此而设计，通过强制加密连接来解决这一问题。 第五步：接收、过滤与垃圾邮件评估 接收MTA接受邮件后，并不会立即将其放入用户收件箱，而是执行一系列检查： SPF（发件人策略框架）：接收服务器查询发件人域名DNS中的TXT记录，该记录列出了授权的发送IP地址。若发送IP不在列表中，则SPF检查失败。 DKIM（域名密钥识别邮件）：发送服务器使用私钥对邮件头部和正文进行加密签名。接收服务器从DNS中获取对应的公钥并验证签名。有效的DKIM签名可证明邮件在传输过程中未被篡改。 DMARC（基于域的邮件身份验证、报告与一致性）：将SPF和DKIM整合在一起。域名所有者发布DMARC策略，规定对身份验证失败的邮件如何处理——`none`（仅监控）、`quarantine`（发送至垃圾邮件）或`reject`（丢弃邮件）。DMARC还支持汇总报告和取证报告。 […]

DNS（域名系统）是一种分层式分布式命名系统，它将人类可读的域名（如 `www.example.com`）转换为机器可读的 IP 地址（如 `192.0.2.1`）。没有 DNS，每位互联网用户都需要记住他们所访问的每个网站、API 端点或邮件服务器的数字地址。DNS 是使现代互联网能够大规模导航的协议。 DNS 的核心是一个全球分布式数据库。查询通过结构化的委托链进行解析——从顶层的根服务器，经过顶级域（TLD）服务器，再到持有特定域名实际记录的权威名称服务器。这种架构使 DNS 同时具备快速、弹性和可扩展性。 为什么 DNS 不仅仅是一本”电话簿” “电话簿”的类比是一个有用的起点，但它大大低估了 DNS 在生产环境中的实际作用。DNS 支撑着： 名称解析——将 FQDN（完全限定域名）转换为 IPv4 和 IPv6 地址 电子邮件路由——MX 记录将 SMTP 流量引导至正确的邮件基础设施 服务发现——SRV 记录允许应用程序动态定位服务（在 SIP、XMPP 和 Kubernetes 中大量使用） 流量工程——Geo-DNS 和加权路由记录实现全球负载均衡和基于延迟的故障转移 安全执行——TXT 记录承载 SPF、DKIM 和 DMARC 策略；DNSSEC 添加加密验证 CDN 编排——CNAME 扁平化和 Anycast 路由允许 CDN 透明地提供最近的边缘节点服务 对于任何管理 VPS 托管环境或独立服务器的人来说，在这个层面上理解 DNS […]

反向DNS (rDNS)记录，也称为PTR记录，是域名系统 (DNS) 的基本组成部分，用于将IP地址映射回域名。此过程与传统的DNS查找相反，传统DNS查找将域名映射到IP地址。rDNS记录对于验证邮件服务器的真实性、增强安全性和防止垃圾邮件至关重要。本指南将详细介绍如何更改您的虚拟专用服务器 (VPS) 的rDNS记录。 了解PTR记录及其重要性 PTR记录是一种用于反向DNS系统的特定类型的DNS记录。以下是PTR记录必要的一些关键原因： 邮件服务器认证：许多邮件服务器利用rDNS来确认发件人域的合法性，从而降低垃圾邮件和网络钓鱼攻击的风险。 网络故障排除：rDNS通过识别IP地址的所有者或用途来帮助诊断网络问题。 建立信任：准确的rDNS记录增强了您的服务器与其他系统之间的信任，促进更顺畅的交互和通信。 更改rDNS记录的步骤 更改rDNS记录涉及多个步骤。以下是更新托管在AlexHost的VPS上的rDNS记录的详细指南： 验证您的账户：确保您拥有一个活跃的AlexHost账户。如果没有，您需要创建一个。在购买VPS Hosting计划后，您可以继续以下步骤。 访问IPAM部分：登录到您的账户并导航到IP地址管理 (IPAM) 部分。在这里，您会找到分配给您的IPv4和IPv6地址。 选择并编辑您的IPv4地址： 选择您要修改rDNS记录的IPv4地址。 点击“显示IP”以访问编辑选项。 更新rDNS条目： 选择“编辑”选项以修改IPv4地址及其关联的rDNS记录。 输入所需的反向DNS值并保存更改。 验证更新：使用像DNSChecker这样的工具来验证您的rDNS记录是否已更新。输入您的IPv4地址并选择PTR选项以检查状态。 注意：rDNS记录更新可能需要24-48小时才能在全球范围内传播，在某些情况下可能需要长达72小时。 关键注意事项和最佳实践 DNS传播时间：对DNS传播要有耐心。更改可能需要一些时间才能在全球所有DNS服务器上反映出来。 记录间的一致性：确保您的rDNS记录与正向DNS记录一致，以避免配置问题。 安全增强：定期更新您的rDNS记录以符合服务器设置或域配置的任何更改。 结论 更改rDNS记录是一个简单的过程，但需要仔细注意细节以确保服务器通信的完整性和安全性。通过遵循上述步骤，您可以有效地管理VPS的rDNS设置，增强功能性和可信度。 常见问题解答 1. DNS和rDNS有什么区别？ DNS将域名映射到IP地址，而rDNS将IP地址映射回域名。 2. 为什么rDNS对邮件服务器很重要？ rDNS有助于验证发送服务器的真实性，减少垃圾邮件并提高电子邮件的可达性。 3. rDNS更改需要多长时间传播？ rDNS更改可能需要24-48小时传播，但在某些情况下可能需要长达72小时。 4. 我可以更改任何IP地址的rDNS吗？ 您只能更改您拥有或由您的托管服务提供商分配给您的IP地址的rDNS。 5. 我如何确保我的rDNS设置正确？ 定期使用像DNSChecker这样的工具检查您的rDNS设置，并确保它们与您的正向DNS记录匹配。

将域名转移到新注册商是网站所有者或系统管理员执行的最重要的管理任务之一。操作正确时，整个过程无缝衔接，零停机时间。操作不当则可能导致DNS传播失败、域名被锁定、授权码过期，甚至意外中断服务长达数天。 本指南全面介绍将域名转移至AlexHost的完整流程——从ICANN政策合规和EPP授权码，到DNS记录更新和批量转移程序——并提供执行过程中所需的技术深度，确保操作无误。 什么是域名转移，EPP如何实现它？ 域名转移是将已注册域名的管理控制权从一个经ICANN认证的注册商转移到另一个注册商的过程。转移不会对域名的注册到期日产生负面影响；在大多数情况下，会在现有注册期限基础上延长一年。 每次注册商间域名转移的技术基础是可扩展供应协议（EPP），定义于RFC 5730。EPP是一种有状态的、基于XML的客户端-服务器协议，标准化了注册商与域名注册局之间的通信方式。它以结构化、经过身份验证且可审计的方式处理域名供应命令——包括<create>、<delete>、<renew>、<update>，以及关键的<transfer>。每个经ICANN认证的注册商都必须支持EPP，这也是为什么您从当前注册商获取的授权码能被接收注册商普遍识别。 ICANN转移政策：开始前必须了解的内容 在发起任何转移之前，您在法律和技术上都受ICANN注册商间转移政策的约束。以下两条条款尤为关键，且经常被误解： ICANN政策第3.7.5条规定，如果域名在过去60天内创建，则禁止转移。如果您昨天注册了一个域名，今天就无法转移——注册局将直接拒绝EPP转移命令。 ICANN政策第3.7.6条规定，如果域名在过去60天内已经转移过，则禁止再次转移。这可防止注册商跳转滥用行为，并保护域名所有者免受未经授权的连续转移。唯一的例外是转回原注册商，前提是双方注册商相互同意或争议解决机构指示。 以下情况还适用ICANN强制规定的转移锁定： 域名处于注册商锁定状态（状态：clientTransferProhibited或serverTransferProhibited） 域名涉及正在进行的UDRP争议 域名的WHOIS联系邮箱无效或无法验证，阻碍确认流程 域名距到期日不足60天——部分注册商在此期间拒绝出站转移 在提交转移请求之前，对照所有这些条件验证您域名的当前状态，可以节省大量时间并防止转移尝试失败。 转移前检查清单：提交任何内容前的五个步骤 在没有准备的情况下仓促进行转移，是导致域名迁移失败或延迟的最常见原因。请先完成此检查清单上的每一项。 第一步：根据ICANN政策验证域名是否符合转移条件 在公开WHOIS记录中查看域名的创建日期和最后转移日期。两者都必须超过60天。使用可靠的WHOIS查询工具，或通过终端中的whois yourdomain.com直接查询注册局。 第二步：在当前注册商处解锁域名 通过信誉良好的注册商注册的每个域名默认都处于锁定状态，以防止未经授权的转移。此锁定在WHOIS记录中显示为EPP状态码clientTransferProhibited。您必须登录当前注册商的控制面板并明确禁用此锁定。该选项通常标记为”转移锁定”、”注册商锁定”或”域名锁定”。禁用后，请等待几分钟让注册局更新状态，然后再继续操作。 第三步：验证并更新WHOIS联系信息 WHOIS记录中的管理联系人电子邮件地址是转移确认请求的发送目标。如果此电子邮件地址已过时、退信，或被不转发消息的隐私代理保护，转移将停滞或完全失败。在发起转移之前，请将管理联系人电子邮件更新为一个正在使用的收件箱。如果启用了WHOIS隐私保护，请临时禁用它，或确认您的注册商隐私服务会转发与转移相关的电子邮件。 第四步：如已启用DNSSEC，请将其禁用 如果您的域名启用了DNSSEC（DNS安全扩展），您必须在转移之前从父区域中删除DS记录。否则可能导致转移后DNS解析失败，因为新注册商的名称服务器将没有相应的DNSKEY记录。请在当前注册商处禁用DNSSEC，确认DS记录已从注册局中删除，然后再进行转移。 第五步：获取EPP授权码（Auth-Code） 向当前注册商申请EPP授权码（也称为转移授权码、auth-info码或域名密钥）。这是一个唯一的字母数字字符串——通常为8到16个字符——以加密方式确认您是发起转移的授权域名持有人。大多数注册商通过控制面板即时提供此代码，或在请求后通过电子邮件发送。该代码具有时效性；许多注册商在7到30天后使其过期。 请妥善保管此代码。任何持有该代码的人都可以发起您的域名转移。 如何发起向AlexHost的域名转移 一旦所有转移前条件都满足，通过AlexHost提交的实际流程非常简单。 单个域名转移 登录您的AlexHost账户，导航至域名注册部分。 选择转移域名选项。 在提供的字段中输入您的域名。 输入从当前注册商获取的EPP授权码。 查看转移详情，确认管理联系人电子邮件，然后提交请求。 此时，AlexHost的系统向相关注册局发送EPP <transfer op="request">命令，包括您的域名、授权码和获得方注册商的凭据。注册局根据其记录验证授权码。 转移期间配置DNS记录 提交转移请求后，您可以在AlexHost控制面板中预先配置DNS记录。这是一个显著的操作优势——通过在转移完成之前设置好您的A记录、MX记录、CNAME记录和TXT记录（包括SPF、DKIM和DMARC条目），您可以最大限度地缩短DNS解析可能不一致的时间窗口。 如果您同时在AlexHost托管网站或电子邮件，现在是将DNS指向正确基础设施的时机。对于管理电子邮件基础设施的团队，AlexHost的电子邮件托管直接与您的域名DNS管理面板集成。 批量域名转移 对于管理大型域名组合的组织，AlexHost支持批量域名转移。这对于将多个注册商的域名整合到单一管理界面的代理商、经销商和企业尤为有用。 批量转移输入格式为： yourdomain.com:AuthCode1 anotherdomain.net:AuthCode2 thirddomain.org:AuthCode3 每行输入一个域名，紧跟冒号和对应的EPP授权码——不加空格。在单次操作中提交整个列表。AlexHost会针对各自的注册局单独处理每个转移请求，因此不同域名可能在不同时间完成，具体取决于转出注册商的响应速度。 转移时间表：提交后会发生什么 了解技术时间表可以避免在等待期间提交不必要的支持工单和产生焦虑。 阶段 时长 […]

域名服务器（NS记录）是权威DNS指针，用于告知全球DNS基础设施哪些服务器持有您域名的最终区域文件。如果NS记录配置不正确，无论您的Web服务器、邮件系统或SSL证书配置得多么完善，您的域名都将无法解析。 本指南涵盖AlexHost的特定域名服务器基础设施，从协议层面解释NS记录的工作原理，并为cPanel与LiteSpeed以及标准共享主机环境提供可操作的配置指导。 什么是域名服务器，为什么它是DNS的基础 域名服务器是一种专用DNS服务器，用于存储和提供一个或多个域名的权威DNS区域。当递归解析器需要查找example.com背后的IP地址时，它不会进行猜测，而是遵循严格的委派链： 解析器查询根域名服务器，后者返回对相应TLD域名服务器的引用（例如，.com、.net、.md）。 TLD域名服务器返回在域名注册商处注册的NS记录，指向该域名的权威域名服务器。 权威域名服务器——即您在注册商处配置的服务器——响应实际的DNS记录：A、AAAA、MX、CNAME、TXT等。 这意味着NS记录不仅仅是技术形式。它们是委派机制，赋予您的托管服务商的DNS服务器回答您域名查询的权限。如果NS记录指向错误的服务器，或者这些服务器无法访问，您的域名将完全失效——所有依赖它的服务都将受到影响。 每个域名必须至少有两条NS记录，指向不同的、独立运营的服务器。这不是建议，而是ICANN政策和DNS协议本身（RFC 1034/1035）强制执行的要求。 DNS解析链在实践中的工作原理 了解完整的解析路径有助于您精确诊断传播延迟和配置错误问题。 当访问者在浏览器中输入您的域名时，将发生以下顺序： 本地缓存检查：操作系统和浏览器检查其本地DNS缓存。如果存在有效的缓存记录（在其TTL内），解析将在此停止。 递归解析器查询：如果没有缓存命中，查询将发送到ISP或用户配置的递归解析器（例如，8.8.8.8、1.1.1.1）。 根服务器引用：解析器联系13个根服务器集群之一，后者返回权威TLD域名服务器地址。 TLD域名服务器响应：TLD服务器（例如，由Verisign运营的.com）返回您在域名注册商处注册的NS记录。 权威应答：解析器直接查询AlexHost的域名服务器，后者返回所请求的A记录、MX记录或其他记录。 响应传递：解析器在记录TTL期间缓存结果，并将答案返回给客户端。 这里的关键认识是NS记录存在于两个位置：在您的域名注册商处（作为委派）以及权威域名服务器本身的区域文件中。两者必须保持一致。两者之间的不匹配——称为无效委派——会导致间歇性解析失败，这类问题出了名地难以诊断。 AlexHost域名服务器基础设施 AlexHost为不同的托管环境运营独立的域名服务器对。使用与您特定托管计划对应的正确服务器对对于正确的DNS解析至关重要。 cPanel托管与LiteSpeed的域名服务器 这些域名服务器为托管在AlexHost的cPanel VPS和LiteSpeed驱动基础设施上的域名提供服务： 域名服务器 IP地址 角色 ns5.alexhost.md 176.123.0.83 主权威域名服务器 ns6.alexhost.md 176.123.0.84 辅助权威域名服务器 ns5.alexhost.md（176.123.0.83）作为LiteSpeed cPanel堆栈上域名的主要DNS权威。所有区域文件更改——A记录、MX记录、子域名——均在此处创建并同步到辅助服务器。 ns6.alexhost.md（176.123.0.84）作为辅助域名服务器。在正确配置的BIND或PowerDNS设置中，辅助服务器从主服务器执行区域传输（AXFR/IXFR），并在主服务器暂时无法访问时独立回答查询。 cPanel共享主机的域名服务器 托管在AlexHost的共享虚拟主机平台上的域名使用专用域名服务器对： 域名服务器 IP地址 角色 ns3.alexhost.md 176.123.0.55 主权威域名服务器 ns4.alexhost.md 176.123.0.60 辅助权威域名服务器 ns3.alexhost.md（176.123.0.55）是共享主机区域的主权威服务器。它保存主区域文件，是DNS传播的真实来源。 ns4.alexhost.md（176.123.0.60）提供地理和运营冗余。如果ns3因网络问题或维护而无法访问，ns4将不间断地继续提供DNS响应。 为什么独立的域名服务器对很重要 为每个托管环境运行独立的域名服务器对是一个具有实际运营优势的架构决策： 故障隔离：针对共享主机域名服务器的配置错误或DDoS攻击不会影响LiteSpeed VPS客户，反之亦然。 独立的TTL和区域管理：每个环境可以独立调整传播行为。 […]

DNS（域名系统）是将人类可读的域名（例如 www.example.com）转换为服务器用于在互联网上路由流量的机器可读 IP 地址的基础协议。如果没有正确配置的 DNS 服务，您的域名将无法访问，电子邮件将无法投递，SSL 证书也无法验证。 本指南将详细介绍配置 AlexHost 免费 DNS 服务的完整流程，包括管理 NS 记录、添加 DNS 区域，以及了解您将遇到的每种记录类型——包括大多数教程完全跳过的关键边缘情况。 什么是 DNS 服务，为什么正确配置至关重要 DNS 的核心是一个分布式、分层的数据库。当用户在浏览器中输入您的域名时，递归解析器会查询一系列权威名称服务器——从根区域开始，然后是 TLD（.com、.net、.org），最后是您域名的权威名称服务器——以获取正确的 IP 地址。 DNS 记录配置错误不仅会降低您网站的速度，还可能导致完全的服务中断、破坏电子邮件投递、使 DKIM 签名失效，并阻止 SSL 证书的域控制验证（DCV）。TTL 值设置过高意味着一个错误可能在全球解析器中持续数小时或数天。这就是为什么在修改任何设置之前，了解 DNS 配置的每一层——而不仅仅是 A 记录——至关重要。 AlexHost 的 DNS 服务支持每个服务实例绑定最多 10 个域名，对于从单一控制面板管理多个项目的开发者和小型企业来说非常实用。 配置 AlexHost 免费 DNS 服务 第一步：进入 DNS 服务订购页面 登录您的 AlexHost 客户区，导航至 服务 > 免费 […]