audit-hosting

托管审计

从头到尾只读。输出为报告；每项修复都必须通过另一项技能单独确认后执行。

调用操作

• 在首次调用每项操作前，先阅读 search 返回的 inputSchema。如果下方某个名称被拒绝并提示未知，请搜索该步骤的用途（例如“ssl status”）。
• 使用 multi-execute 批量读取，每批最多 20 个步骤。每批只能串联同一服务器的操作——Hostinger Connector 将 hosting、wordpress、agency-hosting 和 billing 作为独立服务器运行。某产品组关闭时，跳过其检查并说明跳过了哪些检查。
• 翻阅每个列表，直到覆盖 meta.total 中的所有条目。
• 不要执行 hosting_php_get——它返回的数据量很大，而且与账户健康状况无关。

1. 清点

每台服务器执行一批：

• 执行 hosting_orders_list，参数为 statuses: ["active", "suspended"]。cloud_* 计划名称属于 Cloud；其余名称（hostinger_premium_*、hostinger_business_* 等）属于 Shared。
• 执行 hosting_websites_list——获取每个 Shared 和 Cloud 网站的 website_type、username、order_id 和 is_enabled（false 表示已暂停）。
• 执行 wordpress_installations_list，参数为 ownership: "all"——获取 id、is_valid、validation_error。
• 执行 agency-hosting_orders_list 和 agency-hosting_websites_list-plan——获取 Agency 订单和网站（details.uid、details.type、details.domains、details.state）。

在检查前告知用户计划、网站和 WordPress 安装的数量。对于大型账户，可提出将审计范围限定为一个订单或域名。

2. 检查

对每个 Shared 和 Cloud 网站（跳过 builder 和 horizons）：

• 执行 hosting_ssl_status——标记 failed（附上 last_error）、expired、自定义域名上的 not_installed、is_https_redirect_enabled: false，以及 is_lifetime 为 false 且 expires_at 在 30 天内的情况。终身证书会自动续期。
• Node.js 网站：执行 hosting_get-deployment（最新构建是否失败？查看 build.state；在托管服务器上，执行 hosting_nodejs_list-builds 并设置 per_page: 1），以及执行 hosting_nodejs_list-vulnerabilities，参数为 severities: ["critical", "high"]。

对每个托管账户（username）：执行 hosting_databases_list——标记 disk_usage_mb 超过 max_size_mb 的 80% 的情况。

对每个 WordPress 安装：执行 wordpress_installations_show-core-version（核心漏洞）和 wordpress_plugins_list-installed（存在漏洞的插件和待处理的更新）。

对每个 Agency 订单：执行 agency-hosting_metrics_list-order-resource-usage，参数为 time_frame_hours: 168；并执行 agency-hosting_metrics_list-plan-order-disk-usage，参数为 time_frame_days: 7——标记用量超过计划配额 80% 的情况，并指出占用资源最多的网站。

对每个 Agency 网站：针对 details.domains 中的每个自定义域名执行 agency-hosting_ssl_website-status；标记 details.state 不为 active 的情况。

即将到期的计划（billing 产品）：执行 billing_subscriptions_list，并通过 subscription_id 与托管订单关联——标记 not_renewing，或 is_auto_renewed: false 且 expires_at 在 30 天内的情况。该计划下的所有网站都会随计划一起停机。

从外部检查每个自定义域名：

curl -sS -o /dev/null -w "%{http_code}\n" --max-time 15 https://DOMAIN/
curl -sSI --max-time 15 https://DOMAIN/ | grep -i "^platform"

没有 platform: hostinger 标头，表示该域名无法访问此托管服务。

3. 报告

# Hosting audit
3 plans (2 Shared, 1 Cloud) + 1 Agency · 14 websites (6 WordPress, 3 Node.js, 5 other) · 4 Agency sites

## Fix now
- shop.example.com — latest Node.js build failed 2 days ago → troubleshoot-website
- blog.example.com — contact-form-x 5.2 has a known vulnerability, fixed in 5.3 → maintain-wordpress

## Soon
- example.org — Business plan expires in 12 days, auto-renew off → renew in hPanel
- Agency order 1000000001 — 86% of disk quota, mostly client-a.com

## Worth knowing
- 4 WordPress installs have pending plugin updates → maintain-wordpress

## Healthy
docs.example.com, portfolio.example.com, …

• 立即修复： 网站已停机或无法访问 Hostinger、最新构建失败、WordPress 安装无效、SSL 为 failed 或 expired、存在严重漏洞、网站已暂停。
• 尽快处理： 存在高危漏洞、计划将在 30 天内到期、用量超过配额的 80%、HTTPS 重定向已关闭、非终身证书即将到期。
• 值得了解： 有待处理的更新、存在漏洞的非活动插件。

每项都要注明证据以及用于修复的技能：troubleshoot-website、maintain-wordpress、connect-domain 或 deploy-to-hosting。通过 GitHub 部署的网站上可修补的 npm 漏洞，可以使用 hosting_nodejs_patch-vulnerabilities 修复；该操作会创建拉取请求——可提出此方案，但不要将其作为审计的一部分执行。

API 无法提供的信息

Shared 和 Cloud 计划的 CPU 和内存使用情况、网站备份状态以及 PHP 错误日志。在末尾提及一次，让用户了解审计无法查看哪些内容。