Fly.ioのwwwサブドメインSSLエラーをCloudflareで修正する（エラー525）

Fred· AI Engineer & Developer Educator4 min read

アプリをFly.ioにデプロイしてルートドメインは正常に動作するのに、www.yoursite.comがSSLハンドシェイクエラーをスローしますか？あなただけではありません。このエラー525は、Fly.ioが各ホスト名に個別のSSL証明書を必要とするために発生します。そしてほとんどのデプロイメントガイドはこのステップを完全にスキップしています。

以下は、本番デプロイメントでテスト・検証済みの修正方法です。

問題

Fly.ioにデプロイし、カスタムドメインを追加し、すべてが正常に見えます。そしてwww.yoursite.comにアクセスしようとすると：

Error 525: SSL handshake failed

一方、yoursite.com（wwwなし）は正常に動作します。なぜでしょうか？

なぜこれが起こるか

Fly.ioはLet's Encryptを使用してSSL証明書をプロビジョニングしますが、ここに落とし穴があります：example.comの証明書を追加しても、自動的にwww.example.comはカバーされません。

それらは完全に別のホスト名として扱われます。wwwサブドメイン用の証明書を明示的に追加する必要があります。

解決策（5ステップ）

ステップ1：Fly.io CLIをインストール

まだの場合は、flyctlをインストールします：

# Install flyctl
curl -L https://fly.io/install.sh | sh

# Add to PATH
export FLYCTL_INSTALL="$HOME/.fly"
export PATH="$FLYCTL_INSTALL/bin:$PATH"

# Make it permanent (add to ~/.bashrc or ~/.zshrc)
echo 'export FLYCTL_INSTALL="$HOME/.fly"' >> ~/.bashrc
echo 'export PATH="$FLYCTL_INSTALL/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc

# Verify it works
flyctl version

ステップ2：現在の証明書を確認

まず、どの証明書があるか確認します：

flyctl certs list -a YOUR_APP_NAME

おそらく次のように表示されるでしょう：

Host Name                 Added                Status
example.com              1 month ago          Ready
api.example.com          1 month ago          Ready

何が足りないか気づきましたか？wwwサブドメインです。

ステップ3：www証明書を追加（これで修正されます）

問題を解決する重要なコマンドはこちら：

flyctl certs add www.example.com -a YOUR_APP_NAME

Fly.ioはwwwサブドメイン用のLet's Encrypt SSL証明書を自動的にプロビジョニングします。次のような出力が表示されます：

You are creating a certificate for www.example.com
We are using Let's Encrypt for this certificate.

Your certificate for www.example.com is being issued.
You can validate your ownership of www.example.com by:

1: Adding an AAAA record to your DNS service which reads:
    AAAA @ 2a09:8280:1::X:XXXX

DNS検証について心配しないでください。ルートドメインがすでに動作していれば、wwwサブドメインは自動的に検証されます。

ステップ4：証明書の準備完了を確認

1〜2分待ってから、証明書のステータスを確認します：

flyctl certs show www.example.com -a YOUR_APP_NAME

**"Status: Ready"**を探してください。「Awaiting certificates」と表示されている場合は、もう1分待ってから再度確認してください。

準備ができたら、証明書リストは次のように表示されるはずです：

flyctl certs list -a YOUR_APP_NAME
Host Name                 Added                Status
example.com              1 month ago          Ready
www.example.com          13 seconds ago       Ready

完璧です。

ステップ5：Cloudflare SSL/TLSモードを設定

DNS（推奨）にCloudflareを使用している場合、このステップは重要です。

  1. Cloudflareダッシュボードにログイン
  2. ドメインを選択
  3. SSL/TLS → Overviewに移動
  4. 暗号化モードを**"Full"**に設定（「Flexible」や「Full (strict)」ではなく）

なぜ"Full"か？

  • Flexible: Cloudflareは訪問者にはHTTPSを使用しますが、Fly.ioにはHTTPを使用します（安全でなく、問題が発生します）
  • Full: Cloudflareは訪問者とFly.ioの両方にHTTPSを使用します（正しい）
  • Full (strict): 信頼された認証局が必要ですが、Fly.ioは独自の証明書を管理しています（エラーが発生します）

DNSレコードの設定（Cloudflare）

DNSレコードが正しく設定されていることを確認します：

ルートドメイン（example.com）：

  • タイプ: AまたはAAAA
  • 名前: @（または空白）
  • コンテンツ: Fly.io IPアドレス（flyctl ips listから）
  • プロキシステータス: Proxied（オレンジのクラウドが有効）

wwwサブドメイン（www.example.com）：

  • タイプ: CNAME
  • 名前: www
  • ターゲット: example.com（ルートドメインを指す）
  • プロキシステータス: Proxied（オレンジのクラウドが有効）

オレンジのクラウド（Proxied）は重要です。トラフィックをCloudflareのCDN経由でルーティングし、SSLを有効にします。

すべてをテスト

両方のドメインが動作することを確認します：

# Test root domain
curl -I https://example.com

# Test www subdomain
curl -I https://www.example.com

両方ともHTTP/2 200（またはHTTP/1.1 200）を返すはずです。エラーが発生した場合は、以下のトラブルシューティングセクションを参照してください。

一般的なエラーと修正

エラー525：SSLハンドシェイク失敗

症状: wwwサブドメインがエラー525をスロー、ルートドメインは正常に動作

原因:

  1. Fly.ioにwww証明書がない
  2. Cloudflare SSL/TLSモードが「Flexible」または「Full (strict)」に設定されている

修正:

# Add the www certificate
flyctl certs add www.example.com -a YOUR_APP_NAME

# Wait 2 minutes for certificate issuance
sleep 120

# Verify it's ready
flyctl certs show www.example.com -a YOUR_APP_NAME

また、Cloudflare SSL/TLSモードが**"Full"**に設定されていることを確認してください。

wwwサブドメインが接続タイムアウトを返す

症状: wwwサブドメインがまったくロードされない、エラーページがない

原因:

  1. DNS CNAMEレコードが欠落しているか不正
  2. DNSがCloudflare経由でプロキシされていない
  3. DNS伝播が不完全

修正:

  1. www CNAMEレコードのCloudflare DNS設定を確認
  2. オレンジのクラウド（Proxied）が有効であることを確認
  3. DNS伝播のために5〜15分待つ
  4. ブラウザキャッシュをクリアするか、シークレットモードでテスト

証明書が5分以上「Awaiting Certificates」と表示される

症状: flyctl certs showが「Awaiting certificates」と言い続ける

原因:

  1. DNSレコードがFly.ioを正しく指していない
  2. Cloudflareプロキシが証明書検証に干渉している

修正:

# Verify your DNS records are correct
dig www.example.com

# Check if DNS is resolving to Fly.io
nslookup www.example.com

# If stuck, delete and re-add the certificate
flyctl certs delete www.example.com -a YOUR_APP_NAME
flyctl certs add www.example.com -a YOUR_APP_NAME

ルートドメインは動作、wwwはルートにリダイレクト（両方が必要な場合）

症状: www.example.comにアクセスするとexample.comにリダイレクトする

原因: これはアプリコードでの意図的な動作かもしれません

修正: 両方が独立して動作するようにしたい場合は、以下を確認：

  1. Fly.ioに両方の証明書が存在する
  2. アプリにwww→非wwwへの強制リダイレクトロジックがない
  3. 両方のDNSレコードが正しく設定されている

なぜ個別の証明書が重要か

従来の共有ホスティングでは、ワイルドカードSSL証明書（*.example.com）がすべてのサブドメインをカバーします。しかしFly.ioはLet's Encryptを通じて証明書を個別にプロビジョニングします。

これにより、より多くの制御が可能になりますが、各サブドメインの明示的なセットアップが必要です：

  • example.com → 独自の証明書が必要
  • www.example.com → 独自の証明書が必要
  • api.example.com → 独自の証明書が必要
  • blog.example.com → 独自の証明書が必要

お分かりでしょう。

Fly.io + Cloudflareのベストプラクティス

  1. 本番稼働前に使用予定のすべてのサブドメインに証明書を追加する
  2. Fly.ioデプロイメントにはCloudflareの"Full" SSL/TLSモードを使用する
  3. CDNとDDoS保護のためにCloudflareプロキシ（オレンジのクラウド）を有効にする
  4. サイトを発表する前にwwwと非wwwの両方のバージョンをテストする
  5. どちらか一方のバージョンを強制したい場合はアプリでリダイレクトを設定する

トラブルシューティング用の便利なコマンド

# List all certificates for your app
flyctl certs list -a YOUR_APP_NAME

# View detailed info for a specific certificate
flyctl certs show www.example.com -a YOUR_APP_NAME

# Delete a certificate (if you need to start over)
flyctl certs delete www.example.com -a YOUR_APP_NAME

# Check your app's IP addresses
flyctl ips list -a YOUR_APP_NAME

# Check DNS resolution
dig example.com
dig www.example.com

# Test SSL connection with verbose output
curl -vI https://www.example.com

# Check app status
flyctl status -a YOUR_APP_NAME

# View app logs (useful for debugging)
flyctl logs -a YOUR_APP_NAME

完全セットアップチェックリスト

すべてが正しく設定されていることを確認するためにこのチェックリストを使用してください：

Fly.io証明書：

  • ルートドメイン証明書が存在し「Ready」と表示
  • wwwサブドメイン証明書が存在し「Ready」と表示
  • その他のサブドメインにも証明書を追加済み

Cloudflare DNS：

  • ルートドメイン用のAまたはAAAAレコードがFly.io IPを指している
  • wwwサブドメイン用のCNAMEレコードがルートドメインを指している
  • すべてのレコードでオレンジのクラウド（Proxied）が有効

Cloudflare SSL/TLS：

  • 暗号化モードが「Full」に設定（FlexibleやFull strictではなく）
  • Edge Certificatesが有効なSSLを表示

テスト：

  • https://example.comが200 OKを返す
  • https://www.example.comが200 OKを返す
  • ブラウザでSSL警告がない
  • 両方のドメインがセキュアなロックアイコンを表示

実際の例

ftashark.comの完全なセットアップはこのようになります：

# Check certificates
$ flyctl certs list -a ftashark

Host Name                 Added                Status
ftashark.com              1 month ago          Ready
www.ftashark.com          13 seconds ago       Ready
api.ftashark.com          1 month ago          Ready

Cloudflare DNS：

Type    Name    Content                          Proxy
A       @       66.241.124.123                   Proxied
CNAME   www     ftashark.com                     Proxied
CNAME   api     ftashark.com                     Proxied

Cloudflare SSL/TLS: Fullモード

結果: 3つのURLすべてが有効なSSLで正しく動作。

なぜほとんどのガイドがこれをスキップするか

ほとんどのFly.ioデプロイメントチュートリアルは、アプリを実行し、単一のカスタムドメインを追加することに焦点を当てています。example.comまたはwww.example.comのみを使用し、両方は使用しないと想定しています。

しかし実際には、ユーザーは両方のバージョンを入力します。検索エンジンは両方をインデックスします。そして、トラフィックの半分がSSLエラーにヒットすることは望ましくありません。

www証明書の追加は30秒で済みますが、後で何時間ものデバッグを節約します。

代替案：wwwを非wwwにリダイレクト（または逆）

両方のバージョンを維持したくない場合は、アプリでリダイレクトを設定できます。

オプション1：www → 非wwwにリダイレクト

ほとんどのフレームワークにはこのためのミドルウェアがあります。例えば、Express.jsでは：

app.use((req, res, next) => {
  if (req.hostname.startsWith('www.')) {
    return res.redirect(301, `https://${req.hostname.slice(4)}${req.url}`)
  }
  next()
})

オプション2：非www → wwwにリダイレクト

app.use((req, res, next) => {
  if (!req.hostname.startsWith('www.')) {
    return res.redirect(301, `https://www.${req.hostname}${req.url}`)
  }
  next()
})

ただし、リダイレクトする場合でも、両方の証明書が必要です。そうでないとリダイレクトが機能しません（ユーザーはアプリがリダイレクトする前にSSLエラーにヒットします）。

結論

Fly.ioのwwwサブドメインSSLの問題は、経験豊富な開発者でもつまずく「落とし穴」の1つです。一度知れば修正は簡単です：

  1. www用の個別証明書を追加：flyctl certs add www.example.com -a YOUR_APP_NAME
  2. Cloudflare SSL/TLSを「Full」モードに設定
  3. 証明書の準備ができるまで1〜2分待つ
  4. 両方のドメインをテスト

それだけです。複雑な設定なし、サーバー再起動なし、設定ファイルの編集なし。ほとんどのデプロイメントガイドが言及し忘れる1つのコマンドだけです。

これで、ユーザーはwwwの有無に関係なくサイトにアクセスでき、両方が正しく動作します。

関連ガイド：

リソース：

Fred

Fred

AUTHOR

Full-stack developer with 10+ years building production applications. I've been deploying to Cloudflare's edge network since Workers launched in 2017.

Need a developer who gets it?

POC builds, vibe-coded fixes, and real engineering. Let's talk.

Hire Me →