Cloudflare設定は、Webサイトを高速かつ安全にし、DDoS攻撃への耐性を高めるためにDNS、SSL/TLS、WAF、セキュリティルール、ボットフィルタ、キャッシュの各項目を正しく構成することです。最も安全な基本構成としては、ドメインをCloudflareに追加し、DNSレコードを正確に移行、SSLモードは可能な限りFull (Strict)を選択し、WAFの管理ルールを有効化、不審なリクエストにはチャレンジやレートリミットを適用、攻撃時には「Under Attack Mode」などの防御モードを適切に活用することが重要です。
Cloudflareは、Webサイトと訪問者の間に位置するCDN兼セキュリティレイヤーとして機能します。訪問者がサイトにアクセスすると、リクエストはまずCloudflareネットワークに到達し、ここで悪質なトラフィックがフィルタされ、静的ファイルはキャッシュから配信され、正当なリクエストのみオリジンサーバーに転送されます。この仕組みは特にWordPress、WooCommerce、企業サイト、SaaS管理画面、アクセスの多いメディアサイトに大きなメリットをもたらします。ただし、Cloudflareの設定ミスはSSLエラー、無限リダイレクトループ、管理画面へのアクセス障害、キャッシュによる更新反映遅れやセキュリティホールにつながる可能性もあります。
本ガイドではCloudflareの初期設定から、Webサイトセキュリティに不可欠な各オプションの有効化、DDoS対策の正しい活用、パフォーマンス設定を安全性を損なわずに最適化する方法まで、ステップバイステップで解説します。高速かつ安全で安定したサイトを構築するためには、ドメイン・ホスティング・SSLの基盤をしっかり整えることが大切です: Domain kaydı, Web hosting paketleri, SSL sertifikası.
Cloudflareとは?Webサイトセキュリティにおける役割
CloudflareはDNS管理、CDN、DDoS防御、Webアプリケーションファイアウォール、ボット対策、SSL/TLS管理、トラフィック分析など幅広いクラウド型セキュリティ&パフォーマンスプラットフォームです。従来、訪問者は直接ホスティングサーバーに接続しますが、Cloudflare導入サイトではまずCloudflareのエッジサーバーにアクセスし、悪質なトラフィックはオリジンサーバー到達前に遮断されます。
例えば小規模WordPressサイトの場合、通常は1日2,000アクセス、1分あたり20〜30リクエスト程度ですが、単純なHTTPフラッド攻撃で1分間に20,000リクエストまで急増することも。サーバーのCPUやRAM、帯域制限で応答不能となるリスクもあります。CloudflareはIP評価、行動分析、レートリミット、チャレンジ、DDoSシグネチャによって正規ユーザーと攻撃者を区別し、サイトへのアクセスを守ります。
Cloudflareは万能なセキュリティツールではありません。強固なホスティング基盤、最新ソフトウェア、強固なパスワード、バックアップ、SSL、適切なサーバー設定と併用することで効果を発揮します。特にWordPressの場合、テーマやプラグインの更新、管理画面の保護、パスワードポリシーも依然として重要です: WordPress hosting, WordPress güvenliği.
Cloudflare導入前の準備チェックリスト
Cloudflare移行前に基本的な事前確認を行うことで、設定後のアクセス障害やSSLエラーを防げます。特に本番サイトではDNS変更を計画的に行いましょう。
- 現在のDNSレコードを記録: A, AAAA, CNAME, MX, TXT, SPF, DKIM, DMARCやサブドメインも控えておきます。
- ホスティングIPの確認: Aレコードが間違っているとサイトが別サーバーに誘導されます。
- SSL状態のチェック: オリジンサーバーに有効なSSLがあればCloudflareでFull (Strict)が利用可能です。
- メール関連のレコード注意: MXやメール用CNAME/Aレコードは基本的にプロキシをオフ(DNS only)にします。
- バックアップ取得: DNSとサイトのバックアップを取ることで万一の際に迅速復旧できます。
- メンテナンス時間の選定: ネームサーバー変更は数分で反映されますが、世界的な伝播には最大24時間かかる場合も。
企業サイトの場合、まずDNSレコードを正確に移行し、Webトラフィックを扱うwwwやルートドメインのみプロキシ(オレンジクラウド)にします。メール、FTP、cPanel、webmailなどのサービスは利用目的に応じて慎重に設定。例えばcPanelアクセス用のサブドメインがある場合、DNS only設定が推奨されます: cPanel hosting yönetimi.
Cloudflare DNS設定方法
Cloudflare導入は、ドメインを管理画面に追加するところから始まります。Cloudflareは自動で現在のDNSレコードをスキャンし一覧を表示しますが、全てのレコードが正確に検出されるとは限らないため必ず手動で確認しましょう。
1. ドメインをCloudflareに追加
Cloudflareアカウントにログインし、「Add a site」からドメインを登録します。プラン選択後、DNSレコードを確認します。ルートドメインには通常Aレコード、wwwにはCNAMEレコードがあります。例として以下の構成になります:
- Aレコード: example.com → 192.0.2.10
- CNAMEレコード: www → example.com
- MXレコード: example.com → メールプロバイダー
- TXTレコード: SPF, DKIM, DMARC認証用
ここで重要なのは、どのレコードをCloudflareプロキシ経由にするかです。Webトラフィック用のA/CNAMEはオレンジクラウド(プロキシON)、メールやFTPなど直接サーバー接続が必要な場合はグレー(DNS only)を選びます。
2. ネームサーバーの変更
Cloudflareは2つのネームサーバーを発行します。ドメイン登録業者の管理画面で既存のネームサーバーをCloudflare指定のものに変更します。Hostragonsで管理中のドメインの場合、コントロールパネルから設定可能です: Domain yönetimi。変更後、Cloudflare側で「Active」と表示されるまで待ちます。
3. プロキシ状態の適切な選択
オレンジクラウド(プロキシON)ではHTTP/HTTPSトラフィックがCloudflare経由となりセキュリティ機能が働きます。グレーはDNS解決のみ。WebサイトにはプロキシONを、mail.example.comやftp.example.com等の管理用サブドメインは通常プロキシOFF(DNS only)を推奨します。
SSL/TLS設定:最も安全な構成
CloudflareのSSL/TLS設定は、ブラウザとCloudflare間、Cloudflareとオリジンサーバー間の暗号化方式を決定します。SSLモードの誤選択はCloudflare関連のトラブルの主因です。
Flexible, Full, Full (Strict)の違い
| SSLモード | Cloudflare-訪問者 | Cloudflare-サーバー | 推奨度 |
|---|---|---|---|
| Flexible | HTTPS | HTTP | 一時的以外は非推奨。リダイレクトループやセキュリティリスクあり。 |
| Full | HTTPS | HTTPS | サーバーにSSLあり。ただし証明書の厳格検証なし。 |
| Full (Strict) | HTTPS | HTTPS(有効証明書) | 最も安全な標準。可能な限り選択。 |
プロ用途ではFull (Strict)を目指しましょう。そのためにはオリジンサーバーに有効なSSL証明書が必要です。Let’s Encryptや商用SSL、Cloudflare Origin Certificateも利用可能。HostragonsのホスティングプランならSSL導入・更新プロセスも安心です: SSL sertifikası kurulumu.
Always Use HTTPSとAutomatic HTTPS Rewrites
「Always Use HTTPS」はHTTPリクエストを自動でHTTPSへリダイレクトします。「Automatic HTTPS Rewrites」はページ内の一部HTTPリソースをHTTPSへ書き換えます。混在コンテンツ問題がある場合は、データベースやテーマ内のHTTPリンクを根本的にHTTPS化しましょう。
HSTS利用時の注意点
HSTSはブラウザに対しHTTPS接続のみ許可します。強力なセキュリティですが、SSL構成ミス時には訪問者がサイトにアクセスできなくなることも。まずFull (Strict)+有効SSL+サブドメインやリダイレクト設定が正常か確認し、初期は短いmax-ageで試すのが安全です。
Cloudflare WAF設定でWebアプリセキュリティ強化
WAF(Web Application Firewall)はSQLインジェクション、XSS、ファイルインクルード、悪質ボット、既知のアプリ脆弱性へのリクエストをフィルタします。Cloudflare WAF設定は特にWordPress、Joomla、Laravel、独自CMS、ECサイトで重要です。
管理ルールの有効化
管理ルールはCloudflareが更新する標準セキュリティルールセットです。WordPress専用ルールやOWASP、CVEシグネチャで攻撃面を縮小できます。最初は「Log」や低い影響度で運用し誤検知を確認、問題なければ「Block」や「Managed Challenge」へ切り替えましょう。
カスタムルールで重要領域を保護
独自ルールはサイト構造に応じてピンポイントの防御が可能。例としてwp-login.phpや/adminページへのアクセスを特定国のみ許可、特定URIの怪しいuser-agentをチャレンジに送る等。ただし実ユーザーへの影響に注意。ECサイトで決済ページを誤ってチャレンジにするとコンバージョン低下につながります。
実例:日本向け企業サイトで/wp-adminは国外アクセスにManaged Challenge、海外拠点やリモートスタッフはIP allowlist設定。これでブルートフォース攻撃を大幅に削減しつつ正規ユーザーは維持可能です。
DDoS対策の実践ポイント
DDoS攻撃は大量トラフィックでサイトやサーバーをダウンさせることが目的。Cloudflareの最大の利点は、世界規模のネットワークでトラフィックを受け止め、オリジンサーバーにはクリーンなリクエストのみ転送できる点です。DDoS防御は受動的な「待機」ではなく、状況に応じた「戦略的設定」が鍵になります。
1. Webトラフィックのプロキシを常にON
Cloudflare DDoS防御はプロキシONのレコードのみ有効。ルートドメインやwwwのクラウドがOFFならWebトラフィックは直接サーバーへ。オリジンIPが公開されていないことも重要。古いDNSレコードやメールヘッダー、直接IPアクセスはCloudflareを迂回される原因です。
2. Security LevelとChallenge設定活用
Security Levelは訪問者のリスクスコアに応じてチャレンジ画面を表示します。通常時は「Medium」が多くのサイトに適しています。攻撃時や怪しいトラフィック時は「High」や一時的に「I’m Under Attack Mode」を利用。Under Attack Modeは訪問者に検証画面を表示するため、通常運用では常時ONは避けましょう。
3. レートリミットでリクエスト集中を制御
レートリミットは同じIPやクライアントから一定期間内のリクエスト数を制限します。例えばログインページに1分間20回以上のリクエストがあればチャレンジを適用。APIエンドポイントではより慎重な設定が必要—モバイルアプリや連携サービスがある場合、実際の利用量を把握した上で制限しましょう: API ve entegrasyon güvenliği.
4. オリジンサーバーのファイアウォール強化
高度な対策として、サーバーファイアウォールでCloudflare IPレンジからのHTTP/HTTPSのみ許可する方法があります。これで攻撃者がオリジンIPを知っても直接アクセスできません。ただしCloudflareのIPリストは最新維持が必須、SSHや管理パネル、バックアップサービスなど管理用途は別途考慮が必要です。
ボット対策・ブルートフォース防御
全てのボットトラフィックが悪質なわけではありません。Googlebotなど検索エンジンはインデックスに必須。一方、スパムボットやスクレイピングツール、不正ログイン試行やリソース消費型自動化が問題です。Cloudflareのボット対策は行動分析によってこれらを区別します。
- Bot Fight Mode: 基本的なボットトラフィック削減に有効ですが、外部連携時は動作確認を。
- Turnstile: CAPTCHA代替としてフォームに導入可能。ユーザーフレンドリーな認証。
- ログインページ保護: wp-login.php, xmlrpc.php, adminページはカスタムルールで制限。
- XML-RPC制御: WordPressで不要ならブロックしブルートフォースリスク低減。
- フォームスパム抑制: お問い合わせフォームはTurnstile+レートリミット併用。
実例:WordPressサイトでxmlrpc.phpに毎分千件のPOSTリクエストがある場合、CPU消費が急増します。Cloudflareのカスタムルールでxmlrpc.phpをブロック、Jetpack等必要サービス用IPのみ許可すればサーバー負荷が大幅軽減します。
キャッシュ・パフォーマンス設定:安全性を損なわず高速化

Cloudflareはセキュリティだけでなくパフォーマンス面も強力。静的ファイルを訪問者最寄りのエッジから配信しページ表示速度を向上させます。ただし全てをキャッシュすると問題—ログイン状態、カート、決済、会員ページ、個別コンテンツはキャッシュ対象外としましょう。
推奨キャッシュ設定
- Caching Level: 標準設定が多くのサイトに適合。
- Browser Cache TTL: 静的ファイルは1週間以上推奨。
- Cache Rules: /wp-admin, /cart, /checkout, /my-account等はキャッシュバイパス。
- Always Online: 一時的な障害時に限定的効果。動的サイトでは期待値調整を。
- Purge Cache: デザインやコンテンツ変更時は全消去よりURL指定消去が安全。
パフォーマンス最適化にはホスティング層も重要。LiteSpeed、NVMeディスク、最新PHP、適切なキャッシュプラグインでCloudflareとの相乗効果が得られます: LiteSpeed hosting, web sitesi hızlandırma.
Cloudflareセキュリティ設定のおすすめ初期プロファイル
以下の表は多くの中小規模サイト向けの安全な初期プロファイルです。サイトごとにトラフィックや構造が異なるため実データを見ながら調整しましょう。
| 設定項目 | 推奨値 | 重要ポイント |
|---|---|---|
| SSL/TLS | Full (Strict) | エンドツーエンドで検証済みHTTPSを提供 |
| Always Use HTTPS | ON | HTTPリクエストを安全な接続へ誘導 |
| WAF管理ルール | ON | 既知のWeb攻撃を自動でフィルタ |
| Security Level | Medium | 日常運用に最適なバランス防御 |
| Under Attack Mode | 攻撃時のみ | DDoS時に追加認証を実施 |
| レート制限 | ログイン・APIに適用 | ブルートフォースや悪用を抑制 |
| Cache Rules | 動的ページはバイパス | カートや決済・管理画面のエラー防止 |
| DNSSEC | 可能ならON | DNS詐称対策の追加防御 |
よくあるCloudflare設定ミスと対処法
無限リダイレクトループ
主にCloudflareのSSLモードがFlexibleでオリジンサーバー側にHTTPSリダイレクトがある場合に発生。解決策はサーバーに有効なSSLを導入し、Cloudflare側のSSLモードをFullまたはFull (Strict)に変更。
521, 522, 525エラー
521はサーバーが接続拒否、522はタイムアウト、525はSSLハンドシェイク失敗を示します。Cloudflare IPがファイアウォールで遮断されていないか、ホスティングサーバーが稼働中か、SSL証明書が有効か、DNSレコードが正しいIPを指しているか確認しましょう。
管理画面で更新が反映されない
強すぎるキャッシュルールが主因。管理画面、カート、決済、ユーザーアカウントページはキャッシュ対象外に。WordPressならキャッシュプラグイン+Cloudflare連携でキャッシュ消去を自動化できます。
メール障害
Cloudflareプロキシはメールトラフィックを処理しません。MXレコードは正しいか、メールサーバー指向のレコードはDNS onlyか、SPF/DKIM/DMARC TXTレコードが揃っているか確認しましょう。
安全なCloudflare導入ステップリスト
以下の手順で初心者でも安全かつ実用的な導入が可能です:
- 1. ドメインをCloudflareに追加、DNSレコードを現プロバイダーと比較。
- 2. Webトラフィック用ルート&wwwレコードのプロキシをON。
- 3. メール・FTP・管理サービスはDNS only運用を検討。
- 4. ネームサーバーをドメイン管理画面で変更。
- 5. オリジンサーバーに有効SSLを設定、CloudflareでFull (Strict)選択。
- 6. Always Use HTTPSとAutomatic HTTPS Rewritesを有効化。
- 7. WAF管理ルールをON、初期はログで誤検知を監視。
- 8. ログインページにレートリミットやチャレンジを設定。
- 9. キャッシュルールで動的領域をバイパス。
- 10. 攻撃時はSecurity Levelを上げ、Under Attack Modeを一時的にON。
- 11. サーバーファイアウォールでCloudflare IPレンジのみ許可を検討。
- 12. 毎週Security Events、Analytics、DNSレコードを点検。
このリストは初期導入時のミス防止に有効です。ECサイトや会員制サイトなど高トラフィックの場合、設定変更はアクセスの少ない時間帯に行い、コンバージョン指標もチェックしましょう。
Cloudflare Analyticsとセキュリティイベントの監視
Cloudflare導入後が本当のスタート。Security Eventsではどのルールが何回リクエストを遮断したか、攻撃元の国やIPレンジ、ターゲットURLなどが確認できます。これらのデータに基づき、推測ではなく根拠あるカスタムルール作成が可能です。
例えば、ログで/wp-login.phpに24時間で18,000回の失敗リクエストがあれば、単純にセキュリティレベルを上げるより、そのエンドポイント専用のレートリミットやチャレンジを設定する方が効果的。APIが多用されている場合は全体への厳格ルールより、問題メソッドや国、user-agentごとに狙い撃ちが賢明です。
Cloudflareだけで十分?多層防御の重要性
Cloudflareは強力なレイヤーですが、セキュリティは多層的に設計すべきです。ホスティングの更新が遅れていたり、アプリの脆弱性、管理者パスワードの弱さ、バックアップ不足があればCloudflareだけで全リスクは防げません。安全な運用には信頼できるホスティング、最新PHP、定期バックアップ、SSL、セキュリティプラグイン、ファイル権限、アクセス管理を総合的に取り入れる必要があります。
HostragonsならWebサイトに最適なホスティングプランを選び、Cloudflareと組み合わせて安定したセキュリティとパフォーマンス環境を構築できます。トラフィック増加時には共用ホスティングからVPSやクラウドサーバーへの移行も検討を: VPS sunucu, kurumsal hosting çözümleri.
まとめ:安全なCloudflare設定に向けたバランス戦略
正しいCloudflare設定は、DNSレコードの正確移行、Full (Strict) SSL、WAFルール、慎重なボット対策、レートリミット、適切なキャッシュ例外、攻撃時のDDoSモードで実現します。最良の結果には単発設定ではなく、トラフィックデータを見て定期的に最適化するセキュリティプロセスが不可欠です。
要点:Webトラフィックはプロキシ経由、オリジンサーバーは防御、SSLは厳格モード、WAFやレートリミットは実運用に合わせて調整。ドメイン・ホスティング・SSLの基盤整備にはHostragonsのソリューションもぜひご検討ください: Hostragons hosting paketleri.
よくある質問
Cloudflare設定で最も安全なSSLモードは?
一般的に最も安全なのはFull (Strict)モードです。訪問者⇔Cloudflare、Cloudflare⇔オリジンサーバー双方がHTTPSで通信し、証明書も検証されます。オリジンサーバーに有効なSSL証明書が必要です。
CloudflareのDDoS対策は無料プランでも有効?
無料プランでも基本的なDDoS防御は利用可能。より高度なWAFや詳細なレートリミット、ボット管理、企業向けコントロールは有料プランで拡張されます。中小サイトなら無料プランでも正しく設定すれば十分な防御効果が得られます。
Under Attack Modeは常時ONにすべき?
いいえ。Under Attack Modeは攻撃時のみ一時的に利用すべきです。常時ONだと訪問者が認証画面を頻繁に見ることになり、ユーザー体験に悪影響。通常時はWAFやレートリミット、適切なSecurity Level設定がベストです。
Cloudflare導入でホスティングは不要?
必要です。Cloudflareはサイト前面のセキュリティ・パフォーマンスレイヤーを提供するだけで、サイトファイルやDB、アプリケーションはホスティングやサーバー上に存在します。信頼できるホスティング基盤はCloudflare運用でも不可欠です。
Cloudflareのキャッシュ設定はECサイトで問題になる?
設定ミスがあれば問題となります。カート、決済、ユーザーアカウント、管理画面など動的ページはキャッシュ対象外に。静的ファイルのみキャッシュ、個別コンテンツはバイパス設定すればECサイトでも安全に運用可能です。