FAQ

常见问题

有关服务设置、访问和常见客户操作的实用简短指南。

> 在终端生成 SSH 公钥

为访问服务生成 SSH 公钥，只提交公钥内容。
faq/generate-public-ssh-key-zh

只使用公钥

SSH 使用一对密钥。请只把公钥通常是 .pub 文件的内容粘贴到服务设置中，私钥保留在你的设备上。

终端步骤

  1. 打开 Terminal、Windows Terminal 或 PowerShell。
  2. 运行: ssh-keygen -t ed25519 -C "your-email@example.com"。
  3. 接受默认位置，或选择安全路径。
  4. 显示公钥: cat ~/.ssh/id_ed25519.pub。
  5. 在 Windows PowerShell 中使用: Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub。
  6. 复制完整的 ssh-ed25519 行到 SSH public key 字段。

粘贴前检查

不要复制私钥。如果设置了 passphrase，请安全保存，之后使用密钥时可能需要它。

> 在 Windows 图形界面创建 SSH 密钥

使用 PuTTYgen 创建 SSH 密钥，并只复制公钥。
faq/create-ssh-key-windows-gui-zh

只需要公钥部分

PuTTYgen 会创建公钥和私钥。只把公钥添加到 Cli>_，私钥保存在本机。

Windows 步骤

  1. 打开 PuTTYgen。
  2. 可用时选择 EdDSA / Ed25519。
  3. 仅在需要兼容时选择 RSA 4096。
  4. 点击 Generate，并移动鼠标直到密钥创建完成。
  5. 把私钥保存在你的电脑上。
  6. 复制公钥文本到 SSH public key 字段。

不要共享敏感资料

不要把 .ppk 文件、私钥、passphrase、密码或 token 发送给支持人员或提交到表单。

> 连接自己的域名

切换前检查 authoritative DNS、准确 hostname、记录类型、apex 或 subdomain，以及冲突旧记录。
faq/lianjie-ziji-de-yuming

准确 hostname 决定设置

先确认连接的是 apex 域名如 example.com，还是 subdomain 如 app.example.com。不同情况可能需要不同 DNS 记录和提供商支持。

修改 DNS 前

  1. 确认 authoritative DNS 记录在哪里编辑。
  2. 移除或调整冲突的 A/AAAA、CNAME、ALIAS、ANAME 或 redirect。
  3. 使用该服务和 hostname 推荐的记录类型。
  4. 等待 DNS propagation 后再测试最终 HTTPS。

更安全的 rollback

在新 hostname 正常响应前，不要关闭旧 hosting。出现问题时发送域名、预期目标和公开 DNS 结果，不要发送 registrar login。

> 转移 DNS 区域管理

A/AAAA 指向地址，CNAME 指向 alias，MX 用于邮件，TXT 用于验证、SPF、DKIM 或 DMARC。
faq/zhuanyi-dns-quyu-guanli

不要盲目混合记录

每种 DNS 类型都有不同作用。A 和 AAAA 指向 IP，CNAME 创建 alias，MX 路由邮件，TXT 承载验证和邮件策略，CAA 限制证书颁发机构。

复制记录时

  1. 准确复制 name、type 和 value。
  2. 如果 DNS 规则禁止，不要在已有其他记录的 hostname 上放 CNAME。
  3. DKIM 放在提供商 selector 下，DMARC 通常放在 _dmarc。
  4. 谨慎设置 CAA，错误值可能阻止证书签发。

DNS 失败时

发送 hostname、记录类型、预期值和公开查询结果。不要发送 DNS login，也不要发送带 API tokens 的 screenshots。

> 账户注册与首次登录

创建一个团队可长期使用的工作账户，补全账单资料，并使用不会丢失访问权的邮箱。
faq/account-registration-and-login

一个账户管理订单和服务

把账户作为订单、账单资料、服务、域名和支持沟通的长期入口。建议使用团队可持续访问的工作邮箱。

首次下单前检查

  1. 使用工作邮箱注册。
  2. 如系统要求，完成邮箱确认。
  3. 在付费订单前填写账单资料。
  4. 可用时立即启用双因素认证。

无需发送密码的访问方式

不要通过聊天或 email 发送密码。多人需要访问时，使用团队内部 password manager 或团队流程；支持不需要你的密码。

> 预付余额如何工作

余额会显示当前金额、预计可运行时间、活动服务的每日消耗，以及服务暂停后的可见删除期限。
faq/prepaid-credit-how-it-works

服务运行时会消耗余额

预付服务会按活动时间和所选配置扣减余额。每日价格用于估算当前余额还能让服务运行多久。

避免服务被暂停

  1. 登录后查看余额和预计可运行时间。
  2. 确认订单或变更前查看新的每日价格。
  3. 提前充值，不要等到余额耗尽当天。
  4. 服务暂停后立即查看可能删除的日期。

余额看起来不对时

发送订单号、服务名称和需要核对的时间段。不要发送银行卡资料、passwords、private keys，或包含敏感信息的完整账单。

> 月估算、年估算和真实每日消耗

月价和年价用于比较；预付服务以确认变更后的每日消耗为准。
faq/billing-periods-and-credit-burn

估算不是账单日历

月度估算按 31 天，年度估算按 372 天。实际余额消耗取决于服务活动时间和已确认配置。

价格变化时核对

  1. 比较变更前后的每日消耗。
  2. 更多 CPU、RAM、磁盘或付费选项会提高消耗。
  3. 变更在确认、必要付款并应用后生效。
  4. 保存订单确认和余额历史用于记账。

按具体时间段核对

订单号、服务名称和日期能帮助支持核对消耗。不要发送银行资料，也不要发送包含无关个人信息的 screenshots。

> 付款后的订单状态

付款后订单可能等待支付方确认；只有第一笔明确失败、取消或过期后才应创建重复订单。
faq/order-status-and-payment-confirmation

Pending 不一定是失败

付款页面返回后，订单可能仍在等待支付提供商确认。重复订单会让付款匹配更复杂。

付款后的处理

  1. 付款完成后返回 Cli>_。
  2. 在账户中查看订单状态。
  3. 如果仍为 pending，等待提供商确认。
  4. 出现问题时提供订单号和可见的付款参考。

不需要提供的资料

支持不需要银行卡资料、密码或完整银行确认。订单号、付款时间、可见状态，以及隐藏敏感信息的错误截图通常足够。

> 加快服务设置所需的信息

准备服务名称、域名、存储大小、访问邮箱和 SSH 公钥；不要在表单中填写秘密信息。
faq/service-setup-information-needed

准确输入能减少延迟

订单表单用于服务名称、域名、DNS 计划、存储、CPU、RAM、管理员邮箱或 SSH 公钥。密码、private keys 和 tokens 不应填写。

结账前准备

  1. 选择团队能识别的服务名称。
  2. 决定使用自有域名还是临时 hostname。
  3. 如需要，准备 SSH 公钥。
  4. 按应用需求核对存储和资源。

不要把秘密填进表单

如果不确定某项是否敏感，先询问而不要直接发送。不要发送 private keys、passwords、tokens、database dumps 或完整配置文件。

> 下单后更改 CPU、RAM、磁盘或保留期

从现有服务详情中修改，不要创建重复订单；变更可能影响价格、每日消耗、重启和停机风险。
faq/change-service-resources-after-order

修改现有服务而不是新建服务

如果服务已经运行，应从服务详情修改资源。新订单会创建另一个服务，并可能改变费用和运行行为。

确认变更前

  1. 查看当前 CPU、RAM、磁盘、backup 和 Offsite Archive。
  2. 检查新的每日价格和余额影响。
  3. 阅读重启、维护或停机提示。
  4. 在高风险变更前自行导出重要数据。

变更失败时

发送服务名称、变更时间、可见状态和错误信息。不要发送 private keys、passwords 或 tokens。

> 取消服务与数据删除日期

已开通的服务会先暂停，显示可配置的删除期限，然后才可能永久清理。
faq/cancel-service-and-data-retention

取消不等于立即删除

对于已开通服务，系统会先暂停并显示可配置的删除日期。在此之前可以安排导出或咨询恢复可能性。

取消前确认

  1. 导出需要长期保存的数据。
  2. 查看计划删除的日期和时间。
  3. 不要把 backups 或 Offsite Archive 与服务 lifecycle 删除混淆。
  4. 不确定时在期限前联系支持。

删除期限之后

超过可见日期后，不应假设数据仍可用。如需询问，发送订单号和服务名称，不要发送 exports 或登录秘密。

> Backups 与 restore 请求

Backups 用于操作恢复，不替代导出；restore 可能覆盖更新的数据。
faq/backups-and-restore-requests

Backup 不是归档或导出

Backup 保留期取决于产品和选项。它帮助从错误中恢复，但不能替代自己的导出、审计归档或 Offsite Archive。

清晰的 restore 请求

  1. 提供服务名称和订单号。
  2. 说明希望恢复到的大致时间。
  3. 说明是整个服务还是支持的具体部分。
  4. 附上可见错误，不要发送 passwords、tokens 或 private keys。

Restore 前的影响

如果服务之后已有新数据，restore 可能用较旧状态覆盖它们。请先通知团队，并导出不想丢失的内容。

> Offsite Archive 的用途

Offsite Archive 保存远程归档副本，独立于短期操作 backups 和服务 lifecycle。
faq/offsite-archive-purpose

日常运行之外的归档

Offsite Archive 用于远程归档副本和更长保留期。它不是应用的 live disk，也不是短期操作 backups。

何时启用

  1. 用于需要保存在普通服务之外的数据。
  2. 按合规、业务或 recovery 目标选择保留天数。
  3. 记住费用随存储量和保留时间增长。
  4. 大数据量应同时规划自己的导出流程。

按 MB-days 计费

计费基础是 MB-days：存储了多少数据，以及保留了多少天。费率显示为 EUR/GB/月，结果四舍五入到整分。

> 为 VPS 选择 CPU、RAM 和磁盘

按应用、数据库、cache、logs 和增长选择 VPS；OOM 或持续 swap 表示可能需要更多 RAM。
faq/vps-cpu-ram-and-disk-sizing

从真实负载开始

小型静态站点与数据库、Java 应用、搜索或 build 容器的需求不同。规划时要考虑应用内存、cache、logs、uploads 和增长余量。

计划过小的信号

  1. 出现 OOM、out of memory、process killed 或 swap 时增加 RAM。
  2. 持续计算、压缩或 builds 繁忙时增加 CPU。
  3. 在 filesystem、logs 或数据库占满前增加磁盘。
  4. 变更后确认原来的限制是否消失。

Sizing 所需信息

服务名称、应用类型、可见错误、问题时间，以及当前 CPU、RAM 和磁盘都有帮助。不要发送密码或含秘密的配置文件。

> VPS 什么时候需要 public IP

独立 public IP 适用于 allowlist、inbound 访问、稳定 outbound 来源或绑定地址的服务。
faq/vps-public-ip-options

先确认流量方向

不是每个服务都需要 public IP。它通常用于合作方、提供商或 firewall 的 allowlist、稳定 outbound 来源或特定 inbound 端口。

订购 IP 前的问题

  1. 确认 allowlist 是 inbound、outbound 还是两者。
  2. 外部系统允许时使用 DNS 名称。
  3. 只开放应用真正需要的端口。
  4. 在改变生产访问前把 allowlist 需求发给支持。

默认保持端口关闭

Public IP 不表示要开放所有端口。只为必要服务设计最小访问面，不要发送 passwords、private keys 或秘密 firewall rules。

> VPS 的共享 SSH 访问

未购买 public IP 时，VPS 通过共享 SSH endpoint 和高位端口连接；购买 public IP 后，还会有指向该地址的直接 SSH。
faq/shared-ssh-access-for-vps

为什么使用高位端口

多个 VPS 可以共享同一个公开 SSH endpoint，因此每个服务会分配自己的高位端口。端口是路由到正确 VPS 的一部分。

按访问类型连接

  1. 共享 SSH 时复制服务页上的 username、public host 和高位 port。
  2. 使用 ssh -p <port> <username>@<public-host>。
  3. 如果购买了 public IP，可能会有第二个直接 SSH endpoint，指向该 IP 或其 DNS。
  4. private key 只在本地使用；给支持只发 host、port、username 和可见错误。

购买 public IP 后

Public IP 不会移除共享 endpoint；它会增加一条直接路径，适合 allowlist、监控或直接连接。你可能会看到两种 SSH 路径，除非服务明确显示，否则不要假设 port 22 可用。

> 连接自有域名前的检查清单

切换前检查 authoritative DNS、准确 hostname、记录类型、apex 或 subdomain，以及冲突旧记录。
faq/custom-domain-readiness-checklist

准确 hostname 决定设置

先确认连接的是 apex 域名如 example.com，还是 subdomain 如 app.example.com。不同情况可能需要不同 DNS 记录和提供商支持。

修改 DNS 前

  1. 确认 authoritative DNS 记录在哪里编辑。
  2. 移除或调整冲突的 A/AAAA、CNAME、ALIAS、ANAME 或 redirect。
  3. 使用该服务和 hostname 推荐的记录类型。
  4. 等待 DNS propagation 后再测试最终 HTTPS。

更安全的 rollback

在新 hostname 正常响应前，不要关闭旧 hosting。出现问题时发送域名、预期目标和公开 DNS 结果，不要发送 registrar login。

> 服务常用 DNS 记录类型

A/AAAA 指向地址，CNAME 指向 alias，MX 用于邮件，TXT 用于验证、SPF、DKIM 或 DMARC。
faq/dns-record-types-for-services

不要盲目混合记录

每种 DNS 类型都有不同作用。A 和 AAAA 指向 IP，CNAME 创建 alias，MX 路由邮件，TXT 承载验证和邮件策略，CAA 限制证书颁发机构。

复制记录时

  1. 准确复制 name、type 和 value。
  2. 如果 DNS 规则禁止，不要在已有其他记录的 hostname 上放 CNAME。
  3. DKIM 放在提供商 selector 下，DMARC 通常放在 _dmarc。
  4. 谨慎设置 CAA，错误值可能阻止证书签发。

DNS 失败时

发送 hostname、记录类型、预期值和公开查询结果。不要发送 DNS login，也不要发送带 API tokens 的 screenshots。

> DNS propagation 与 TTL，不按分钟承诺

TTL 决定 resolver 可缓存旧答案多久；切换期间旧结果和新结果可能同时存在。
faq/dns-propagation-and-ttl

Propagation 本质是 cache

DNS 没有精确到分钟的承诺。authoritative DNS 修改后，不同 resolvers 可能在 TTL cache 过期前仍返回旧答案或新答案。

计划变更时

  1. 如果提供商允许，提前降低 TTL。
  2. 在 cache 过期期间不要反复随机修改。
  3. 结果不一致时从多个 resolvers 测试。
  4. 记录变更时间、旧值、新值和 TTL。

诊断所需上下文

说明 hostname、目标、可见旧答案、新答案、TTL 和变更时间。不要发送 DNS 账户访问权限或提供商内部备注。

> Nextcloud 存储规划

容量应包含用户文件、共享文件夹、versions、trash、previews、sync overhead 和团队增长。
faq/nextcloud-storage-planning

Nextcloud 的增长不只来自可见文件

用户文件、共享文件夹、deleted files、version history、previews、thumbnails、sync clients 和 imports 都会消耗容量。接近上限时 uploads 或 sync 可能失败。

订购容量前

  1. 估算当前用户数据和共享文件夹。
  2. 为 versions、trash、previews 和 sync overhead 留余量。
  3. 考虑大型 imports、新团队和预期增长。
  4. 在用户触及限制前增加存储。

报告 sync 问题

发送服务容量、大致使用量、问题时间和客户端错误。不要发送个人文件、passwords 或用户 exports，除非通过安全方式明确要求。

> 将仓库迁移到 Gitea

迁移 Git 仓库时同时规划 LFS、submodules、权限、deploy keys、webhooks 和 CI/CD。
faq/gitea-repository-migration

迁移不只是 git clone

除了仓库历史，还需要迁移或重新设置 owners、teams、protected branches、protected tags、Git LFS、submodules、deploy keys、webhooks 和 CI/CD。

cutover 前检查

  1. 列出仓库、owners、访问组和 automation accounts。
  2. 检查 Git LFS、submodules、branch protections 和 tag protections。
  3. 迁移后测试 clone、push、Git LFS、submodules 和 CI。
  4. 迁移后撤销或轮换旧 tokens，不要共享其值。

迁移中的秘密

不要发送 tokens、private keys、deploy key 的私有部分或 CI secrets。仓库名称、集成类型和可见错误通常足够。

> Listmonk 发件域名基础

发送活动前准备 sender domain 或 subdomain、From 身份、SPF、DKIM、DMARC、bounce 和 unsubscribe。
faq/listmonk-sender-domain-basics

投递率从域名开始

Listmonk 需要清晰的 From 身份和可验证的 DNS 记录。SPF、DKIM 和 DMARC 应与发件域名或子域名保持一致。

第一封 campaign 前

  1. 选择 sender domain 或 subdomain 和 From name。
  2. 添加 verification records、SPF、DKIM selector 和 DMARC。
  3. 测试 delivery、bounce 或 Return-Path 以及邮件链接。
  4. 检查 unsubscribe 和 List-Unsubscribe。

不要在 ticket 中放邮件秘密

诊断时发送域名、记录类型、公开 DNS 值和错误。不要发送 SMTP passwords、API tokens、private DKIM key 或收件人导出。

> Classic Hosting Runtime 设置

Classic Hosting 可使用 auto 或 manual Runtime；CPU、RAM、存储、backups、Offsite Archive、uploads、cache 和 logs 会影响价格和稳定性。
faq/classic-hosting-runtime-settings

Auto 不是唯一正确选择

Auto Runtime 适合可识别项目；当需要明确选择 Nginx、Apache、FrankenPHP 或特定语言 runtime 时，manual mode 更合适。PHP selector 仅在所选 runtime 支持时使用。

deploy 前设置

  1. 按 framework 和 build 方式选择 auto 或 manual Runtime。
  2. 仅在支持的 PHP 场景选择 PHP 8.2、8.3 或 8.4。
  3. 按数据和访问量设置 CPU、RAM、disk、backup retention 和 Offsite Archive。
  4. deploy 后测试 uploads、cache、logs 和可见应用错误。

应用无法启动时

发送 runtime mode、语言或 PHP version、可见错误、改动内容和 deploy 时间。不要发送 .env、passwords、tokens 或含秘密的完整 logs。

> 可以安全发给支持的信息

最有帮助的是订单号、服务名、域名、时间、public hosts、ports、hosting 设置、截图和可见错误，不包含秘密。
faq/support-safe-information-to-share

上下文比秘密更有用

支持收到订单号、服务名、域名、public host 或 port、问题时间、变更内容和准确可见错误时能更快处理。

安全消息内容

  1. 说明订单、服务、域名、时间和出错步骤。
  2. 对于 hosting，提供 runtime、PHP 或 language、CPU、RAM、disk、uploads、cache 和不含秘密的 logs。
  3. 截图前遮盖 passwords、tokens、private keys 和个人数据。
  4. 不确定能否发送时，先询问而不要直接发送数据。

绝不要发送这些内容

不要发送 passwords、private keys、recovery seeds、API tokens、session cookies、database exports、完整 .env、含秘密的完整 logs 或内部基础设施细节。