## この記事でわかること

- 「https にならない」現象を 5 つのパターンに分けて原因を特定
- 各パターンの即時対処
- レンタルサーバー / 自社サーバー / Cloudflare 別の確認手順
- 復旧後に必ず確認すべき周辺項目

SSL の役割や仕組みの基礎は [SSL とは｜Web 担当者向けにわかりやすく解説](/blog/ssl-basics-smb) で整理しています。

## 「https にならない」は実は別の現象が混じっている

「https にならない」と一言で言っても、実態は大きく 5 つのパターンに分かれます。

1. **証明書エラー画面が出る**（鍵マーク無し / 警告画面）
2. **タイムアウト / 接続できない**（ページが永遠に読み込み中）
3. **http にリダイレクトされてしまう**（https 入力したのに http に戻る）
4. **mixed content の警告**（鍵マーク有りだが「保護されていない通信」混在）
5. **DNS レベルで応答が無い**（「サーバーが見つかりません」）

![「https にならない」5 つのパターン分類](/blog/https-not-loading-fix/five-patterns.svg)

それぞれ原因が異なるので、まず自社の症状がどれかを特定します。

## パターン 1: 証明書エラーが出る

### 主な原因

- SSL 証明書の **期限切れ**
- **中間証明書の不備**（チェーンの不完全インストール）
- **ドメイン名と証明書の不一致**（CN / SAN の不整合）
- **自己署名証明書**を本番に使ってしまっている

### 対処

[SSL 期限切れの警告が出た時の直し方](/blog/ssl-expired-warning-fix) で詳しく解説しています。エラーコード（`NET::ERR_CERT_DATE_INVALID` 等）を確認すると原因が一発で分かります。

## パターン 2: タイムアウト / 接続できない

### 主な原因

- **443 番ポートが閉じている**（ファイアウォール設定）
- **Web サーバー（nginx / Apache）が停止している**
- **ロードバランサーやリバースプロキシの設定不備**
- **SSL 証明書のインストール後にサーバー再起動していない**

### 確認方法

```bash
# ポートが開いているか
nc -zv example.co.jp 443

# HTTPS で実際に応答するか
curl -v https://example.co.jp/

# サーバー側でリッスン状況を確認（root 権限）
sudo ss -tlnp | grep :443
```

### 対処

- **443 が閉じている**: ファイアウォール（iptables / firewalld / クラウドのセキュリティグループ）で 443 を解放
- **Web サーバー停止**: `systemctl status nginx` 等で状態確認 → `systemctl restart nginx`
- **設定不備**: 設定ファイルの構文チェック（`nginx -t`）→ 修正 → リロード

## パターン 3: http にリダイレクトされてしまう

### 主な原因

- **`.htaccess` や nginx 設定で http 強制リダイレクト**になっている
- **CMS（WordPress 等）の URL 設定が http のまま**
- **CDN（Cloudflare 等）の SSL モード設定不備**

### 確認方法

```bash
# リダイレクトの挙動を見る
curl -IL https://example.co.jp/
```

`Location: http://...` が出ていれば https → http リダイレクトが発火しています。

### 対処

- **`.htaccess`**: http に飛ばすルールを削除し、逆に http → https のリダイレクトに書き換え
  ```
  RewriteEngine On
  RewriteCond %{HTTPS} off
  RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
  ```
- **WordPress**: 「設定」→ 「一般」で「WordPress アドレス」「サイトアドレス」を `https://...` に変更
- **Cloudflare**: 「SSL/TLS」→ 「概要」で **Full** または **Full (strict)** モードに設定

## パターン 4: mixed content の警告

### 症状

- 鍵マークは出ているが「保護されていない通信」と表示される
- ブラウザのコンソールに `Mixed Content: The page at 'https://...' was loaded over HTTPS, but requested an insecure resource 'http://...'` と出る

### 主な原因

サイト本体は https で配信されているが、**読み込んでいる画像 / CSS / JS / iframe が http** になっている状態。WordPress で http 時代に投稿した記事が残っているケース、外部サービスのタグが http のまま埋め込まれているケースが代表的。

### 対処

1. **コンソールで警告対象の URL を全部リストアップ**
2. **DB / ファイルから http の URL を一括置換**
   ```bash
   # WordPress の場合（バックアップ取ってから実行）
   wp search-replace 'http://example.co.jp' 'https://example.co.jp'
   ```
3. **外部サービス埋め込み（YouTube、Google Maps、決済ボタン等）も https 版に差し替え**

WordPress 特有の mixed content 解消手順（DB 一括置換、テーマファイル内のハードコード書き換え等）は別記事で順次解説する予定です。

## パターン 5: DNS レベルで応答が無い

### 症状

- 「このサイトにアクセスできません」「サーバーが見つかりません」
- DNS_PROBE_FINISHED_NXDOMAIN

### 主な原因

- ドメインの **A レコード未設定**
- ドメインの **期限切れ**
- DNS の **伝播遅延**（最近 DNS 変更した直後）

### 確認方法

```bash
# A レコードが返るか
dig example.co.jp A +short

# 親 NS が返るか
dig example.co.jp NS +short

# WHOIS で期限を確認
whois example.co.jp | grep -i expir
```

### 対処

- **A レコード未設定**: DNS 管理画面でレコードを追加
- **ドメイン期限切れ**: レジストラの管理画面で更新（[ドメイン更新忘れの復旧手順](/blog/domain-renewal-recovery) を参照）
- **伝播遅延**: 数時間〜48 時間待つ

## 環境別のチェック手順

### Xserver の場合

1. サーバーパネル → 「SSL 設定」 で対象ドメインの SSL が有効になっているか
2. 反映まで数十分かかる場合あり
3. 詳しくは [Xserver の SSL 設定と自動更新](/blog/xserver-ssl-setup) を参照

### Cloudflare 配下の場合

![Cloudflare の SSL/TLS モード 4 種](/blog/https-not-loading-fix/cloudflare-ssl-modes.svg)

1. ダッシュボード → 「SSL/TLS」 → 「概要」のモードを確認
   - **Off**: HTTPS が動かない
   - **Flexible**: ブラウザ ↔ Cloudflare は HTTPS、Cloudflare ↔ オリジンは HTTP（mixed content の温床）
   - **Full**: 両区間 HTTPS、オリジンの証明書チェックは緩い
   - **Full (strict)**: 両区間 HTTPS、オリジン証明書もチェック（推奨）
2. 「Edge Certificates」で Universal SSL の状態（Active / Pending）を確認
3. CAA レコードが Cloudflare の発行を許可しているか

### 自社サーバー / VPS の場合

1. nginx / Apache の設定ファイルで `listen 443 ssl;` 等が指定されているか
2. 証明書ファイル（.crt と .key）のパスが正しいか
3. 中間証明書（intermediate）が結合されているか
4. ファイアウォールで 443 が開いているか

## 復旧したら必ず確認すること

### 1. 全ページで mixed content が出ていないか

トップページだけ確認するのではなく、主要ページ（フォーム、商品ページ、ブログ等）でブラウザコンソールに警告が出ていないか確認します。

### 2. HSTS の設定状況

HSTS が有効な状態で証明書エラーが起きると、ユーザーは強制的に https を試みるため、復旧前は警告画面のままになります。HSTS の max-age 設定は [SSL 証明書 単発チェック](/ssl/check) で確認できます。

### 3. リダイレクト設計

http → https のリダイレクトが 301（恒久的）になっているか、www あり / 無しが揃っているか、を確認します。

### 4. 検索エンジンのインデックス再登録

復旧後、Google Search Console で「URL 検査」 → 「インデックス登録をリクエスト」を実行すると、修正後の状態が早く反映されます。

## まとめ

- 「https にならない」は 5 パターンに分かれる：証明書エラー / タイムアウト / リダイレクト / mixed content / DNS
- ブラウザのエラーコード、curl の出力、コンソールの警告で原因を機械的に切り分け
- レンタルサーバー / Cloudflare / 自社サーバーで確認場所が異なる
- 復旧後は mixed content / HSTS / リダイレクト設計の点検も忘れずに

## まずは現状を把握しましょう

自社サイトの HTTPS / SSL 関連の状態は、[SSL 証明書 単発チェック](/ssl/check) で 30 秒で確認できます。HTTPS 接続成功・証明書期限・HSTS・HTTP/2 / 3 対応・CT log の発行履歴をまとめてレポートします。

緊急対応が必要、または「自社で原因が特定できない」状況であれば、[お問い合わせフォーム](/contact) で「SSL 関連のご相談」を選択してご連絡ください。スポット対応（5 万円〜）で 24〜48 時間以内に切り分けと応急処置をご提案します。