URLを開いたら別のページへ移動した、HTTPSへ転送したつもりなのに結果が分からない。そんなときは、転送元の応答と転送先を順に確認します。この記事では、ITtripが運営する「ぱっとネット」のHTTP・リダイレクト確認を使って、URL・回数・ステータスを読み取る手順を紹介します。
ぱっとネットからの測定は、ページ本文を取得するGETではなくHEAD要求で応答ヘッダーを調べます。画面が表示されたかという確認と組み合わせると、どこで応答が変わったかを整理できます。
公開URLを入力してCloudflareから調べる
今回は、末尾のスラッシュがない次の公開URLを使います。最初からスラッシュを付けると確認対象が変わるため、そのまま入力してください。
https://net.ittrip.xyz/tools/qr- 「HTTP・リダイレクト確認」を開く。
- 「調べるURL」に「https://net.ittrip.xyz/tools/qr」を入力する。
- 「測定する場所」を「ぱっとネット（Cloudflare）」にする。
- 「調べる」を押し、HTTP応答の確認結果を見る。
入力するのは、外部からアクセスしてよい公開URLに限ります。管理画面、非公開の共有リンク、認証情報やトークンを含むURLは避けてください。端末内の文字変換と異なり、この診断は入力したURLをサーバーへ送り、対象へ接続します。
307から200への結果を読む
2026年10月2日に確認した画面例では、最初のURLが307を返し、Location: /tools/qr/を示しました。転送先を調べると200が返り、最後に確認したURLは末尾スラッシュ付きになりました。
| 順番 | 確認したURL | HTTPステータス・転送先 |
|---|---|---|
| 1 | https://net.ittrip.xyz/tools/qr | 307 → /tools/qr/ |
| 2 | https://net.ittrip.xyz/tools/qr/ | 200 |
/tools/qr/はホスト名を省略した相対的な転送先です。この例では元のURLと組み合わせて、https://net.ittrip.xyz/tools/qr/へ進みます。最後の200は、この測定元からHEAD要求への成功応答があったことを意味します。ページ内の機能やログイン後の動作まで成功した証明ではありません。
結果には「HTTPステータス」「測定元」「最後に確認したURL」などが表示されます。問い合わせに使う場合は「結果全体をコピー」で保存し、測定日時も添えると、設定変更前後の比較がしやすくなります。
ステータスと転送回数を分けて確認する
| ステータス | 主な意味・見る点 |
|---|---|
| 301・308 | 恒久的な転送。意図した新しいURLか確認 |
| 302・307 | 一時的な転送。転送先と利用目的を確認 |
| 200 | 要求の成功。今回確認するのはHEAD応答 |
| 403・405 | 要求の拒否やメソッド非対応の可能性 |
| 404・5xx | 対象の存在やサーバー側の状態を追加確認 |
コードの意味はRFC 9110のHTTPステータスの説明が基準です。サイト移転で永続的な転送が必要な場合は、Google検索のリダイレクト解説も確認します。コードを変えただけで検索掲載や順位が保証されるわけではありません。
直接測定は最大3回の転送を追跡します。同じURLへ戻る循環や3回を超える転送を検出すると、エラーとして中止します。その場合は最後まで正常に到達したとは扱わず、HTTPS化、ホスト名統一、末尾スラッシュなどのルールが互いに戻し合っていないか調べてください。
ブラウザーと結果が違うときの切り分け
通常ブラウザーでは開けるのに403や405が出る場合、HEADの拒否、アクセス元の制限、不正アクセス対策などが考えられます。403・405だけでサイトの故障と断定せず、ブラウザー表示と管理するサーバーのログも確認します。
HEADは本文を受け取らない方法です。このツールはJavaScriptやHTMLのmeta refreshを実行しないため、それらによる画面遷移や、GET要求での転送動作は保証しません。Cookieやログイン状態に応じて応答が変わるページも、通常ブラウザーと同じ条件にはなりません。HEADの定義はRFC 9110のHEADの項目で確認できます。
別の測定元を確認したい場合は、Globalpingの外部プローブを選ぶ方法もあります。実行前の同意が必要で、対象URLと測定結果はGlobalpingへ送信され、計測IDから公開参照でき、最大約6か月保持されるため、公開してよいURLだけを指定してください。外部プローブは指定URLへのHEAD応答1回を確認し、転送先を自動追跡しません。直接測定の連続した結果と同じものとして比較しないようにします。
原因に合わせて設定とDNSを見直す
HTTPからHTTPSへの転送ルールをApacheで修正する場合は、ApacheのHTTPSリダイレクト設定が参考になります。リバースプロキシのURL書き換えが関係する場合は、ApacheのリバースプロキシとURL書き換えを、利用している構成に合わせて確認してください。
移転後に古いサーバーが見える場合は、転送ルールに加えてDNSの回答も確認します。DNS変更後に古いサイトが表示される場合の切り分けでは、2つの公開DNSを比較する方法を説明しています。修正後は転送元から再測定し、意図した転送先と最終応答を確認しましょう。
コメント