Synology NASで運用する公開WebサーバをCloudflareプロキシ化する実践ガイド

masao — Mon, 12 Jan 2026 06:13:47 +0000

Cloudflare DNS を用いた DDNS 設定および、acme.sh による DNS-01 チャレンジを利用した証明書取得設定を行うことで、Cloudflare のプロキシ機能（いわゆる「オレンジ雲」）を安全に有効化することができます。
Cloudflare プロキシを利用すると、公開 Web サーバへの通信は一度 Cloudflare が受け取り、その後オリジンサーバへ中継されます。この中継過程で WAF や Bot 対策などのセキュリティ機能、ならびに CDN によるキャッシュ配信が動作するため、セキュリティ向上とパフォーマンス改善の両立が期待できます。
本記事では、Synology NAS で運用している Web サーバを対象に、Cloudflare プロキシを有効化する基本設定と、さらに運用品質を高めるための追加設定について解説します。

以下の記事で、Synology NASで構築したWebサイトのDDNSをCloudflareのDNSで実現する設定方法について紹介しています。

参考　Synology NASで構築したWebサイトのDDNSをCloudflareのDNSで実現する設定方法

また、以下の記事で、Synology NASでacme.sh（DNS-01）を使った証明書自動更新について紹介しています。

参考　Cloudflareプロキシ有効時でも使える！Synology NASでacme.sh（DNS-01）を使った証明書自動更新

ここまでで、Synology NASをCloudflareと連携させるための下準備は整いました。
DDNSをCloudflareに統合し、Cloudflareプロキシを有効にした状態でもacme.shを用いて証明書を自動更新できる環境が構築できています。

本記事では、これらの仕組みを前提として、いよいよSynology NAS上で運用している公開WebサーバをCloudflareプロキシ配下に置く構成について解説します。
まずは、管理系アクセスと公開Webアクセスを分離した、本記事で想定する全体構成を整理していきます。

前提　本記事でのDSM（OS）バージョンはSynology DSM 7.3を用いています。

1.想定構成
2.DNS 設定をプロキシ ON にする
3.オリジンサーバとの通信設定（SSL/TLS 暗号化）
4.DNS の A レコード（IPv4）を削除する（推奨）
5.Synology NAS の Firewall 設定（推奨）
6.リバースプロキシ設定（対象があれば必須）
7.Cloudflare セキュリティルールの設定（推奨）
8.Cloudflare キャッシュルールの設定（推奨）
9.まとめ

1.想定構成

本記事で想定する構成は以下のとおりです。

DSM 管理画面・Synology Web アプリ：Synology DDNS 経由（Cloudflare 対象外）
公開 Web サーバ：独自ドメイン + Cloudflare プロキシ
IPv6 優先構成
個人／SOHO 運用を想定

管理系のアクセス経路と公開 Web サーバの経路を分離することで、安定性とセキュリティのバランスを取る設計としています。

2.DNS 設定をプロキシ ON にする

Cloudflare ダッシュボードの「DNS」設定画面で、対象となるレコードのプロキシステータスを ON（プロキシ済み）にします。

これにより、外部から DNS 参照された際に返される IP アドレスは Cloudflare の IP アドレスとなり、クライアントからのリクエストは一度 Cloudflare が受け取った後、オリジンサーバへ中継されます。この中継処理の中で、Cloudflare のセキュリティ機能や CDN 機能が動作します。

なお、DNS レコードに登録されている IP アドレス自体は、オリジンサーバの実 IP のままで問題ありません。変更されるのは、外部から参照された際に返却される IP アドレスのみです。

Synology NASキット 2ベイ DS225+ クアッドCPU搭載 2GBメモリ搭載 2.5GbE-NIC スタンダードユーザー向け DiskStation

Synology

Amazon

Rakuten

Synology NASキット 2ベイ DS223 クアッドコアCPU 2GBメモリ搭載ミドルライトユーザー向け国内正規代理店品電話サポート対応品 DiskStation

Synology

Amazon

Rakuten

3.オリジンサーバとの通信設定（SSL/TLS 暗号化）

Cloudflare ダッシュボードの「SSL/TLS」→「概要」にて、SSL/TLS 暗号化モードを「フル（厳密）」に設定します。（デフォルトでは「自動」になっているため、明示的に変更します。）

「フル（厳密）」を選択することで、Cloudflare とオリジンサーバ間の通信も TLS により暗号化され、オリジンサーバ側の証明書検証が行われます。※ここで、事前に acme.sh を用いて取得した証明書が使用されます。

なお、Cloudflare のクライアント証明書は Cloudflare とオリジンサーバ間の通信専用であり、ローカル環境などからの直接アクセスには利用できません。

ここまでの設定で、Cloudflare プロキシは有効化され、デフォルト状態でも一定のセキュリティ機能と CDN による配信が機能します。以下は、さらに運用品質を一段高めるための推奨設定です。

Seagate IronWolf 3.5インチ 4TB 内蔵ハードディスク HDD CMR 6Gb/s 256MB 5400rpm ST4000VN006/EC

SEAGATE

Amazon

Rakuten

Western Digital ウエスタンデジタル WD Red 内蔵 HDD ハードディスク 4TB SMR 3.5インチ SATA 5400rpm キャッシュ256MB NAS メーカー保証3年 WD40EFAX-EC 【国内正規取扱代理店】

ウエスタンデジタル

Amazon

Rakuten

【NAS用拡張メモリ】Synology D4NESO-2666-4G [DDR4-2,666-SODIMM / 4GB / Synology NAS専用] 国内正規代理店品

Synology

Amazon

Rakuten

4.DNS の A レコード（IPv4）を削除する（推奨）

Cloudflare ダッシュボードの DNS 設定画面で、対象ドメインの A レコード（IPv4）を削除します。

目的は、Cloudflare とオリジンサーバ間の通信を IPv6 のみに限定することです。フレッツ光環境では IPv6 経由通信の方が効率的な場合が多く、通信品質の向上が期待できます。

公開 Web サイトとしての IPv4 アクセスについては、Cloudflare プロキシを有効化しているため Cloudflare 側で IPv4 アドレスが提供され、IPv4 からのアクセスも問題なくオリジンサーバへ中継されます。

本設定は、オリジンサーバが IPv6 で安定して外部通信可能な環境であることが前提です。IPv6 未対応環境では、A レコード削除によりサイトが到達不能になる可能性があります。
※ IPv6到達性に不安がある場合は、まずAレコードを残したまま運用し、問題がないことを確認してから削除することを推奨します。

5.Synology NAS の Firewall 設定（推奨）

公開 Web サーバへの入口が Cloudflare に集約されたため、Synology NAS 側では Firewall 設定により到達経路を大幅に絞ることができます。

HTTPS（443）に対して、以下のルールを設定します。

送信元が Cloudflare の IP アドレスの場合は許可（公開 Web サーバ用）
送信元が日本（JP）の場合は許可（DSM 管理画面や Synology Web アプリ用）

CloudflareのIPアドレスについては以下にて公開されています。

IP範囲

本ページは、Cloudflareの現行IP範囲の最も信用できるソースであることを意図としています。

前述の設定により Cloudflare とオリジンサーバ間通信を IPv6 のみに限定している場合、Cloudflare の IP アドレス条件も IPv6 のみとします。

送信元を JP に限定したルールは、公開 Web サーバ以外の用途（DSM 管理画面やモバイルアプリ利用）を考慮して残しています。この構成でも、HTTPS ポートに対する不正アクセスは大幅に減少します。

Cloudflare IPレンジは 定期的な更新が必要です。
※ただし更新履歴にもある通り、数年に1度ある程度となります。

acme.sh による証明書取得設定を行っている場合、HTTP（80）ポートを公開する必要はありません。未実施の場合も含め、原則としてポート 80 は閉じ、可能であればゲートウェイ機器側でクローズすることを推奨します。

6.リバースプロキシ設定（対象があれば必須）

Cloudflare プロキシ経由のアクセスでは、オリジンサーバから見る送信元 IP アドレスは Cloudflare の IP アドレスとなります。そのため、アクセス解析などでクライアントの実 IP アドレスが必要なアプリについては、HTTP ヘッダを通じて実 IP を引き渡す設定が必要です。

以下のカスタムヘッダをリバースプロキシ設定に追加します。

CF-IPCountry : $http_cf_ipcountry
CF-RegionCode : $http_cf_regioncode
CF-IPCity : $http_cf_ipcity
X-Forwarded-For : $http_cf_connecting_ip
X-Real-IP : $http_cf_connecting_ip

これらの設定は、DSM の「コントロールパネル」→「ログインポータル」→「詳細設定」→「リバースプロキシ」から、必要なアプリごとに設定します。

すべてのアプリに一律で設定するのではなく、実 IP が必要なアプリに限定して設定することが重要です。

7.Cloudflare セキュリティルールの設定（推奨）

Cloudflare の WAF 機能を利用すると、L7 レベルで柔軟な条件指定によるアクセス制御が可能です。これを活用することで、不正アクセスや既知攻撃への耐性を高めることができます。

設定箇所はCloudflare ダッシュボードの「セキュリティ」→「セキュリティルール」→「カスタムルール」です。以下は WordPress サイトを想定した設定例です。

管理画面を日本 IP のみに限定
- 条件式: (starts_with(http.request.uri.path, "/wp-admin") and http.request.uri.path ne "/wp-admin/admin-ajax.php" and ip.src.country ne "JP")
- アクション: ブロック
高リスクエンドポイントの遮断
- 条件式: (http.request.uri.path eq "/xmlrpc.php") or (starts_with(http.request.uri.path, "/wp-json/wp/v2/users"))
- アクション: ブロック
悪名高いファイルスキャンの遮断
- 条件式: (http.request.uri.path contains "/.env") or (http.request.uri.path contains "/.git") or (http.request.uri.path contains "/wp-config.php")
- アクション: ブロック
PHP 直叩きの抑止
- 条件式: (ends_with(http.request.uri.path, ".php"))
- アクション: マネージドチャレンジ

マネージドチャレンジは、正規ユーザーのブラウザアクセスを許可しつつ、Bot などの不正アクセスのみを排除できる点が特徴です。これらの設定はあくまで一例であり、利用している CMS やアプリケーションに応じて調整が必要です。

8.Cloudflare キャッシュルールの設定（推奨）

Cloudflare の CDN 機能はデフォルトではキャッシュ対象が限定的であり、HTML ドキュメントは基本的にキャッシュされません。Cache Rules を設定することで、キャッシュ対象を明示的に指定できます。

設定箇所はCloudflare ダッシュボードの「Caching」→「Cache Rules」です。
以下は WordPress サイトを想定した設定例です。

ログイン中ユーザーをキャッシュ除外
- 条件式: (http.cookie contains "wordpress_logged_in_")
- 実行内容: キャッシュをバイパス
管理画面・API をキャッシュ除外
- 条件式: (starts_with(http.request.uri.path, "/wp-admin/")) or (starts_with(http.request.uri.path, "/wp-login")) or (starts_with(http.request.uri.path, "/wp-json"))
- 実行内容: キャッシュをバイパス
静的ファイルをキャッシュ対象
- 条件式: (starts_with(http.request.uri.path, "/wp-content/"))
- 実行内容: キャッシュの対象
- TTL: 1 日
- ブラウザ TTL: オリジンをオーバーライドし 1 日
一般ページをキャッシュ対象
- 条件式: (http.host eq "masao-tec.com")
- 実行内容: キャッシュの対象
- TTL: 2 時間