生产部署与日常管理
适用版本：v3.8.0。把演示换成真实业务前，先确定流量入口、管理入口、数据保留与恢复方式。 太一部署在客户端与源站之间；域名指向太一，太一把允许的请求代理到源站。
1. 选择拓扑与访问边界
| 场景 | 部署方式 | 要准备什么 |
|---|---|---|
| 一个网站或小团队 | 一台 tiyi run，含控制台和本机数据面 |
Linux、持久磁盘、域名/证书、可达源站；Community 免费完整 |
| CDN/负载均衡后保护应用 | CDN/LB → 太一 → 源站 | 精确的代理信任链；只从预期入口接收流量 |
| 多地域或多台入口 | 一个 Controller + 远端 Agents | 可达的 HTTPS 管理地址、远端节点配额 license、同版本节点 |
| 离线或内网 | 签名文件离线安装 | 上传证书、离线 Geo 数据、可达内部源站和备份位置 |
仅有一个可写 Controller，没有内置主备选举或自动控制面故障切换。远端 Agent 在 Controller 中断时继续使用最后接受的配置， 但无法接收新配置；管理、注册和集中视图会中断。备份恢复方案应覆盖这一点。 CPU、内存、磁盘需求取决于流量、规则、正文/上传上限和证据保留。用自己的请求进行容量测试，不把演示结果当容量承诺。
2. 保护管理入口与状态
从完整配置起点开始：管理监听为 0.0.0.0:8080，网站监听 80/443。
首次管理在浏览器打开 http://服务器IP:8080。需要团队 HTTPS 入口时，可通过已有 HTTPS 反向代理转发到管理监听，
或把专用管理域名作为太一 HTTPS 站点，源站设为 http://127.0.0.1:8080。
先申请覆盖该域名的证书，验证登录、刷新与长连接，再开放给指定管理网络；启用 auth.refresh_cookie_secure: true。
对外 TLS 配置见HTTPS 操作。保留 SSH 与本地 socket 作为恢复入口。
将 /var/lib/tiyi 放在持久磁盘；上传暂存需要可写的磁盘目录，不能用 tmpfs 代替所有持久存储。
固定 JWT 密钥，保留数据库配套的 kek.bin；不要重建或丢失 KEK。systemd 的 tiyi 用户必须能读配置和密钥、写状态目录。
不要直接改 SQLite、生成的 Caddy 配置或 Agent 身份文件。
3. 位于 CDN / 代理之后
直接接入时默认以连接对端为客户端。经过 CDN/LB 时，在 防护策略 → 客户端 IP 配置真实的代理链：
先创建/启用可信代理出口的 IP 列表，再选择需要验证的转发头；不要信任来自任意来源的 X-Forwarded-For。
手工地址列表可从以下格式开始，在 IP 列表编辑器粘贴，或通过 CLI replace 文件导入：
# Replace with the actual proxy egress networks
192.0.2.10/32
2001:db8:10::/48
示例地址只是文档保留网段，必须替换为真实代理出口。代理信任列表必须非空且使用永久条目；不支持带 TTL 的条目。
Cloudflare 等订阅初始暂停，先检查来源与解析结果再启用。订阅失败时保留最后接受的快照，需处理“更新受保护”的原因。
用 sudo tiyi trust show 检查，并用 tiyi trust test --help 构造代理 peer 与转发头测试。
再发送真实请求，在日志里核对解析客户端 IP；IP、国家、限速都会依赖这个值。
4. 添加远端节点
Community 包含本机节点，远端节点数为 0。先在 系统管理 → 关于 导入合法签名许可，或配置 license.key_path。
确保远端机器到 Controller 的 HTTPS URL 可达，节点与 Controller 使用同一个 v3.8.0 构建；各节点都必须能访问其源站。
Controller 的 /download/tiyi 返回自身平台二进制，生成脚本的主机应与其 OS/架构匹配。
在 节点 → 安装远端节点 输入可达地址、标签、有效期与节点数，生成安装命令。 复制页面推荐的 systemd 命令到目标主机执行；页面自动追踪这次注册与配置结果，不需要手写 token 文件。 CLI 可直接生成安装命令（在 Controller 主机执行）：
sudo tiyi agents install-command --controller-url https://tiyi.example.com \
--tag edge --ttl-seconds 3600 --max-nodes 1
复制输出的命令，到目标节点执行；不要在 Controller 上执行。命令包含短期安装凭据，勿公开粘贴。
需要审核完整脚本和有效期时，在同一命令后加 --json；需要前台方式则加 --foreground。
注册后执行 sudo tiyi agents list，核对节点在线、配置已应用、源站健康，并向该节点发送真实站点请求。
仅在线不代表已服务；离线与在线但应用失败分别排查。
不同架构的节点应先准备同版本正确平台二进制，按前台/服务高级说明接入。
跨旧版本升级至 v3.8.0 需要重建状态并重新注册，不是普通滚动更新。
保存站点会向内置节点及全部已注册节点下发配置，离线节点在重连后接收。节点分组用于组织节点和相关运维操作，不会把站点自动限制在某一组；所有接收配置的节点都要具备对应源站可达性。
5. 用户、角色与单点登录
在 系统管理 → 用户 / 角色 / 认证 管理账号、权限、LDAP/AD、RADIUS、OIDC、SAML 和 TOTP MFA。 先保留可验证的本地管理员恢复路径；外部认证证明身份，不自动赋予任意角色，先准备匹配用户与权限。 LDAP/RADIUS 的进程配置完整示例见tiyi.yaml；浏览器型 OIDC/SAML 在认证设置填写提供商给出的 issuer/metadata、client 与回调信息。 精确复用控制台显示的回调 URL，在身份提供商登记后测试新浏览器会话；不要凭示例猜 URL。 分配日常运维或只读角色，API 自动化权限参见完整权限表。MFA 恢复码离线保管。
6. 日志、告警、外部系统与备份
先在总览核对请求/阻断计数，在日志中检查样本和证据；明细并不保证为每一个请求永久保留。
在 系统管理 → 设置 → 日志与证据 选择保留与采样策略，设置实际可承担的磁盘配额。
请求证据可能包含原始 Cookie、Authorization 与正文，限制读取权限和保留时间。
从告警与通知配置真实接收通道；SIEM 从处理流量的节点发出，检查各节点到目的端的连通性。
Prometheus 使用仅导出指标的接入步骤；/healthz 只做存活检查，深层健康用 sudo tiyi system health 或本地 /readyz。
AI Copilot 默认关闭，按需配置服务提供商并明确哪些调查数据允许发送；输出是建议，不自动修改策略。 备份必须包含完整状态目录、配置/环境文件、KEK、证书、license 和可恢复的旧二进制；按备份与迁移进行一致冷备并实际演练恢复。