troubleshoot-website

ウェブサイトのトラブルシューティング

ウェブサイトと症状を入力すると、原因、その根拠、解決策が提示されます。原因を明示し、ユーザーが解決策に同意するまでは、読み取り専用で操作してください。

オペレーションの呼び出し

• 各オペレーションを初めて呼び出す前に、search が返す inputSchema を確認してください。以下の名前が不明なオペレーションとして拒否された場合は、その手順で行う操作（例：「ssl status」）を search してください。
• 読み取り操作は multi-execute でまとめ、手順間で値を渡すには $steps.<i>.<path> を使用します。例："$steps.0.data.0.username"。バッチは最初に失敗した時点で停止します。
• Hostinger Connector は各製品を個別の MCP サーバー（hosting、wordpress、agency-hosting、domains、dns）として実行するため、1つのバッチで連結できるのは同じサーバーのオペレーションのみです。search でオペレーションが見つからない場合、その製品グループは Connector で無効になっています。有効にするようユーザーに依頼してください。

1. ウェブサイトを見つける

両方の検索を実行し、以降のすべての呼び出しで結果を使用してください。

• hosting_websites_list に domain を指定します。共有プランとクラウドプランが対象です。フィルターは部分一致のため、domain が問い合わせ対象と完全に一致するエントリーを選択してください。username、order_id、website_type を保持してください。すべての hosting_* および wordpress_* 呼び出しでは、username と domain がキーになります。
• agency-hosting_websites_list-plan に domain を指定します。Agency Plan が対象です。details.uid（すべての agency-hosting_* 呼び出しで使う website_uid）、details.type、details.ipv4、details.domains を保持してください。

どちらにも見つからない場合、そのドメインはこのアカウントのウェブサイトではありません。その旨を伝え、どこを指しているかを示してください（手順2）。

2. 外部から確認する

手順1と並行して、以下を実行してください。

curl -sS -o /dev/null -w "%{http_code} ttfb=%{time_starttransfer}s %{redirect_url}\n" https://DOMAIN/
curl -sSI https://DOMAIN/
dig +short NS DOMAIN; dig +short A DOMAIN; dig +short CAA DOMAIN

• Hostinger のレスポンスに platform: hostinger と panel: hpanel が含まれない場合、または DNS が別の場所を指している場合、トラフィックはこのホスティングに到達していません。connect-domain スキルに引き継いでください。
• 証明書または TLS のエラー → SSL。
• 5xx、空白ページ、またはエラーページ → ウェブサイトの種類別。
• 古いコンテンツが 200 で表示される場合 → キャッシュ：hosting_cache_clear-website（Hostinger CDN も消去します。WordPress がサブフォルダーにある場合は directory を渡してください）。WordPress では wordpress_litespeed-cache_purge-lite-speed も実行します。Agency の場合は agency-hosting_cache_clear-website を実行します。
• 初回応答が遅い場合 → サイトの表示が遅い場合。Hostinger CDN の背後では、x-hcdn-upstream-rt がオリジンの応答時間を秒単位で示します。この値が小さい場合、サーバーはボトルネックではありません。

3. ウェブサイトの種類別

website_type（共有／クラウド）または details.type（Agency）に応じて分岐します。builder と horizons のサイトはこれらのオペレーションでは管理できません。ユーザーに hPanel へ案内してください。

Node.js (nodejs)

hosting_get-deployment（ログ、失敗分析、保存済み設定を含む最新ビルド）、hosting_nodejs_runtime-logs（period: "1h"、levels: ["ERROR", "WARN"]）、hosting_nodejs_list-environment-variables（キーのみ。値は常にマスクされます）をまとめて実行します。hosting_get-deployment がないホストサーバーでは、代わりに hosting_nodejs_list-builds（per_page: 3）を使用します。

• 最新ビルドのステータスが failed：hosting_get-deployment にすでに analysis が含まれています（ビルドごとに1回取得してください。APIは呼び出すたびに分析を再実行し、1分あたり5回まで実行できます）。フレームワークの誤検出、出力ディレクトリの誤り、または entry_file の不足が通常の原因です。返された buildSettings をプロジェクトと照合し、appType、outputDirectory、buildScript、entryFile を修正して再デプロイしてください。Git デプロイではこれらの設定が保存されるため、以降のプッシュでも正しくビルドされます。ホストサーバーでは、そのビルドについて hosting_nodejs_analyse-failed-build を1回実行してから hosting_nodejs_build-logs を実行します。hosting_nodejs_build-settings と照合し、hosting_nodejs_start-build で再ビルドして、hosting_nodejs_update-build-settings で値を保存します。
• ビルドは completed だがアプリでエラーが発生する：ランタイムログを確認します。last_deployed_at より前のログは前回のデプロイに属します。コードが読み込む変数がキーの一覧にない場合は、deploy-to-hosting スキルの環境変数の手順で修正します。Access denied for user '…'@'::1' は、アプリが localhost に接続していることを意味します。DB_HOST は 127.0.0.1 にする必要があります。
• プロセスが応答しない：hosting_nodejs_restart-application を実行します（再ビルドせずに再起動します）。

WordPress (wordpress)

username と domain を指定した wordpress_installations_list で、すべての wordpress_* 呼び出しに使うインストールの id を取得します。wordpress_installations_check-if-are-valid（software_ids: [id]、force: true）、wordpress_plugins_list-installed、wordpress_maintenance_show-status をまとめて実行します。

• 無効なインストール：validation_error に問題が示されます。
• プラグインまたはテーマの変更後に動作しなくなった：wordpress_plugins_deactivate で疑わしいものを1つずつ無効化します（キューに入るため、数秒待ちます）。各無効化の後にステップ2の確認を再実行し、原因ではなかったものは wordpress_plugins_activate で再有効化します。
• メンテナンスページが表示されたままになる：enabled: false を指定して wordpress_maintenance_toggle を実行します。
• 「データベース接続の確立中にエラーが発生しました」：domain を指定して hosting_databases_list を実行します。破損したテーブルは hosting_databases_repair で修復します（バックグラウンドで実行されます）。シークレットを含むファイルは拒否されるため、API 経由で wp-config.php を読み取ることはできません。認証情報を確認する場合は、ユーザーに hosting_databases_phpmyadmin-link を案内してください。
• メモリまたはアップロードサイズのエラー → PHP。

静的サイトまたは PHP（other）

• / で 403 または 404 が発生する：max_depth: 1 を指定して hosting_files_list-website-and-directories を実行します。index.html または index.php はドキュメントルートに配置する必要があります。1階層下に見つかった場合、アーカイブが1階層深くパッケージ化されています。deploy-to-hosting スキルを使って、階層をフラットにして再デプロイします。
• hosting_files_website-content で .htaccess やその他の設定ファイルを読み取ります。
• PHP エラー → PHP。

PHP

hosting_php_get はすべての拡張機能とオプションを返す（約25 KB）ため、PHP の問題がある場合にのみ呼び出します。hosting_php_update-version でバージョンを切り替えます。hosting_php_update-options は値をプランの上限（hosting_php_get の max）に黙って制限するため、適用された値を読み戻して確認します。Agency：agency-hosting_php_list-options-for-website を実行してから、agency-hosting_php_replace-website-options を実行します。これは全置換なので、維持するカスタムオプションをすべて送信してください。

Agency プランのサイト

agency-hosting_websites_get で状態とクォータを確認し、agency-hosting_websites_list-processes で失敗したジョブ（SSL 設定、バックアップなど）を確認します。また、agency-hosting_wordpress_settings でコアのバージョン、LiteSpeed、オブジェクトキャッシュ、メンテナンスモードを確認できます。wordpress_installations_list でサイトが返されない場合は、プラグインを wp-admin から管理します。

SSL

Shared および Cloud の場合、hosting_ssl_status：

• not_installed または failed（last_error に理由が記載されています）：hosting_ssl_install が成功するには、ドメインが Hostinger を参照し、CAA レコードがある場合は letsencrypt.org を許可している必要があります。ステータスを active または failed になるまで確認します。
• installing または waiting_for_retry：待機してください。別のインストール要求を送ると 422 が返されます。
• 無料の *.hostingersite.com サブドメインではプラットフォーム証明書が使用されます。仕様上、インストールを実行すると 422 が返されます。
• 証明書が active でもブラウザーに警告が表示される場合：is_https_redirect_enabled が false なら hosting_ssl_toggle-https-redirect でリダイレクトを有効にしてください。そうでなければ、ページが http:// のアセット（混在コンテンツ）を読み込んでいるため、アプリ側で変更する必要があります。

Agency の場合、ドメインごとに agency-hosting_ssl_website-status を確認します。各ドメインで、証明書の設定は 7 日間に 3 回まで、リクエストは 1 分に 1 回までです。agency-hosting_ssl_install-website または agency-hosting_ssl_reinstall-website を実行する前に agency-hosting_websites_list-processes を確認し、ループで再試行しないでください。

サイトの表示が遅い

• WordPress：wordpress_litespeed-cache_show-lite-speed-status と wordpress_object-cache_show-memcached-status を確認します。通常、wordpress_object-cache_toggle-memcached で Memcached を有効にするのが手早く効果的です。
• その他のサイト：サーバーキャッシュが無効になっているか、開発モードが有効なままになっている可能性があります。どちらにも状態を読み取る操作はありません。キャッシュがすでに有効な場合、hosting_cache_toggle-website に enabled: true を指定しても何も起こりません。hosting_cache_toggle-cacheless に enabled: false を指定すると、開発モードが無効になります。
• PHP 7.x は 8.x より大幅に遅く動作します。アプリが対応している場合は、hosting_php_get で確認できるサポート対象の 8.x バージョンを提案してください。
• Agency：agency-hosting_metrics_list-order-resource-usage に time_frame_hours: 24 を指定すると、プランの上限に対するウェブサイトごとの CPU、メモリ、プロセス数を確認できます。
• Shared および Cloud では、API から CPU やメモリのメトリクスを取得できません。リソース上限が原因と考えられる場合は、ユーザーに hPanel のリソース使用状況ページを案内してください。

修正を適用する

原因、根拠、提案する変更を 1 つだけ伝え、ユーザーの同意を得てから変更を適用してください。その後、手順 2 の確認を再実行し、キューに入ったジョブがあれば先に完了を待って、問題が解消したことを示します。API で実行できない操作が修正に必要な場合は、その旨を伝え、該当する hPanel のページを案内してください。

API では利用できない機能

• ウェブサイトのバックアップと復元 — hPanel の Backups ページ。
• Shared および Cloud プランの CPU、メモリ、プロセス使用状況。
• PHP のエラーログとアクセスログ。