Cloudflare

準備中のサイトを、URLでは共有したい。でも、検索や一般ユーザーにはまだ見せたくない。 Hugoで作っているサイトの公開前チェック、WordPressのリニューアル確認、ローカルで動かしている検証アプリの共有では、この状態がよくあります。自分だけで見るならlocalhostで足りますが、確認相手に見てもらうには外から開けるURLが必要です。 そこで使いやすいのが、Cloudflare Zero TrustのAccessです。 この記事では、preview.araisun.comのような確認用ホスト名にCloudflare Accessをかけ、許可したメールアドレスだけOne-time PINで通す流れを整理します。Cloudflare Tunnelは「previewを外へ出す道」として短く扱い、Tunnel自体の作り方はローカルで立ち上げたサーバーをSSL経由で外部URL公開できるCloudflare Tunnel に任せます。 主役は、Cloudflare Accessのapplication、policy、One-time PIN、動作確認です。 先に結論 Cloudflare配下のドメインで準備中サイトを共有するなら、Basic認証だけでなくCloudflare Accessも候補になります。 Accessを使うと、originへリクエストを通す前にCloudflare側で認証できます。確認してほしい人のメールアドレスをAccess policyに入れ、その人だけOne-time PINでログインできるようにします。共有するのは共通パスワードではなくURLとメール認証の案内です。 今回の例では、preview.araisun.comを準備中サイトの確認用URLにします。Access applicationでこのホスト名を保護し、policyで許可メールを指定し、許可メール、未許可メール、別ブラウザ、スマホ回線、Access logsを順番に確認します。 Tunnelを使う場合でも、この記事ではTunnelの細かい手順には入りません。Tunnelは公開URLへつなぐ道、Accessはその手前で誰を通すかを決める関門、と分けて考えます。 Cloudflare Accessで守れるもの Cloudflare Accessは、Cloudflareを通るリクエストの前段に認証レイヤーを置く機能です。self-hosted applicationとしてpreview.araisun.comのような公開ホスト名を登録し、Access policyに一致したユーザーだけをoriginへ通します。 準備中サイトで使うなら、守る対象は次のような入口です。 preview.araisun.comのホスト名全体 /adminのような特定path stagingやpreview用のサブドメイン この記事では、準備中サイト全体を見せるか見せないかを制御したいので、preview.araisun.com全体を保護対象にします。/adminだけを守る設定にはしません。 Access applicationは、作っただけで全員を通すものではありません。基本は「許可条件に一致した人だけ通す」という考え方です。だから、applicationを作ったあとに、誰を通すかをAccess policyで決めるところが重要になります。 ただし、Accessが守れるのはCloudflare経由の入口です。VPSやnginxのorigin IP、別ホスト名、直アクセス用の経路が残っている場合は、そこから迂回される可能性があります。この点は後半で分けて確認します。 Basic認証とAccessの使い分け Basic認証は、origin側でIDとパスワードを確認する方法です。nginxやApacheで設定でき、Cloudflareを使わない環境でも動きます。短期間の簡単な保護や、自分だけが見るページなら今でも選択肢になります。 一方で、確認相手へ見せる運用になると、Basic認証には少し面倒なところがあります。 IDとパスワードを相手へ送る必要がある 複数人へ同じパスワードを共有しがち 確認が終わった人だけ外す運用がやりにくい ブラウザ標準の認証ダイアログが確認用として少し硬い Cloudflare Accessなら、確認してほしい人のメールアドレスをpolicyに追加します。確認が終わったら、そのメールアドレスを外します。共通パスワードを配って後から変更するよりも、人単位の出し入れがしやすくなります。 もちろん、AccessがBasic認証を常に置き換えるわけではありません。Cloudflareを使っていない環境、サーバー内だけで完結したい環境、単純な一時保護ならBasic認証の方が早いこともあります。 すでにCloudflareをCDN / proxyとして使っていて、メールアドレス単位で少人数に見せたい。そういう準備中サイトでは、Accessの方が自然に扱える場面があります。 Tunnelは道、Accessは認証の関門 Cloudflare TunnelとCloudflare Accessは、役割を分けて考えると混乱しにくくなります。 Cloudflare Tunnelは、ローカルサーバーやprivateなoriginをCloudflareへつなぐ道です。たとえばローカルでHugo previewを動かしているなら、Tunnel側では次のような対応を作ります。 preview.araisun.com -> http://localhost:1313 この設定を作ると、preview.araisun.comからローカルのHugo previewへ届く道ができます。Tunnelの作成、public hostname、DNS、cloudflaredの常駐化などはCloudflare Tunnelの記事 で扱っているので、ここでは広げません。 Accessは、その道の手前に置く認証の関門です。preview.araisun.comに来た人をCloudflare側で止め、メールアドレスとOne-time PINで確認します。許可した人だけをTunnelの先へ通し、Hugo previewを見せます。 ...

Hugo のような静的サイトは、HTML を配信するだけならとても軽いのですが、 POST /api/... のような 小さい受付口 を足したくなることがあります。 例えば次のような用途です。 記事末尾の軽いリアクション お問い合わせの簡易受付 Slack への通知トリガー ちょっとした webhook の受け口 このとき、サイト全体を動的構成へ寄せるほどではないが、POST /api/... だけは欲しい、という場面があります。 そういう用途にちょうどよいのが Cloudflare Worker です。 今回は、Hugo サイトに軽いリアクション導線を追加した実例をもとに、 Cloudflare Worker + D1 + Slack でサーバーレスな受付口を作る方法 を、実際のファイルと設定をそのまま出しながらまとめます。 Cloudflare Worker と D1 は何をするものか まず役割を分けておきます。 Cloudflare Worker Cloudflare Worker は、Cloudflare のエッジ上で動くサーバーレス実行環境です。 ざっくり言うと、Cloudflare 側に小さな API を置ける仕組み です。 今回の用途では、POST /api/like を Worker で受けます。 Cloudflare D1 Cloudflare D1 は、Cloudflare が提供している SQL データベースです。 SQLite に近い感覚で使え、Worker から直接読み書きできます。 今回の用途では、次のようなイベント記録を保存します。 どの記事に対するリアクションか 同じ visitor がすでに送っていないか いつ送られたか Slack Incoming Webhook 通知先です。 新しいイベントがあったときだけ Slack に飛ばします。 ...

Cloudflare Tunnelを使うと、手元のPCやVPSで動いているHugoのローカルプレビューを、ポート開放なしでHTTPSの外部URLとして公開できます。 自分のブラウザだけで確認するならlocalhost:1313で十分ですが、誰かに見てもらうには外からアクセスできるURLが必要です。 開発中に一時的に共有したいだけなら、cloudflared tunnel --urlで十分です。 同じURLを継続して使いたい場合は、Cloudflare管理下の独自ドメインをTunnelへ紐付けます。 この記事では、一時URLで試す最短手順と、preview.example.comのような固定URLにする手順を分けて整理します。 先に結論 Hugoのローカルプレビューを一時的に外部共有したいだけなら、次の2ステップで足ります。 Hugoのローカルサーバーをhttp://localhost:1313で起動する 別ターミナルでcloudflared tunnel --url http://localhost:1313を実行する これでtrycloudflare.comの一時的なHTTPS URLが払い出されます。 確認相手へそのURLを送れば、相手は自分のブラウザからHugoプレビューを見られます。 同じURLを継続して使いたい場合だけ、cloudflared tunnel login、cloudflared tunnel create、config.yml、cloudflared tunnel route dnsへ進みます。固定URL化する場合は、Cloudflareに追加済みのドメインと、Cloudflare側のDNS管理が必要です。 Cloudflare Tunnelでできること Cloudflare Tunnelは、ローカルやprivateなoriginをCloudflareへつなぐための仕組みです。 Hugoのプレビュー用途では、次のような場面で便利です。 公開前の記事やデザインを、固定URLで確認してもらいたい ルーターやVPS側のinboundポートを開けずに、外部から見える確認URLを作りたい 手元のHugoサーバーを、HTTPSでスマホや別のネットワークから確認したい 最初は一時URLで試し、必要になったらpreview.example.comのような固定URLにしたい 逆に、公開サーバーとして恒久運用するなら、Tunnelだけでなく、再起動、ログ、監視、nginx側の設定も別で考える必要があります。VPS上で本番配信する流れは、Ubuntuでnginxを導入して最初の公開設定をする手順 も参考になります。 Cloudflare Tunnelは何をしているのか cloudflaredは、手元のPCやVPS上で動くCloudflare Tunnel用のコネクタです。 外から直接localhost:1313へアクセスするのではなく、cloudflaredがローカル側からCloudflareへoutbound接続を張ります。ブラウザから来たリクエストはCloudflareに入り、Tunnelを通ってcloudflaredへ届き、最後にHugoのローカルサーバーへ流れます。 この形にすると、ローカル側でinboundポートを開けたり、ローカルサーバーのために証明書を直接管理したりしなくても、HTTPSの外部URLを作れます。 インストール macOSならHomebrewでcloudflaredを入れます。 brew install cloudflared 最短で一時URLを発行して試す まずHugoのローカルサーバーを起動します。 hugo server --bind 127.0.0.1 --port 1313 --disableFastRender 別ターミナルで、HugoのローカルサーバーをCloudflare Tunnelへ渡します。 cloudflared tunnel --url http://localhost:1313 実行すると、https://xxxx.trycloudflare.comのような一時URLが表示されます。 このURLは開発・テスト・一時共有向けです。固定URLや継続運用が必要になったら、次のnamed tunnel構成へ進みます。 Hugo以外の開発サーバーでも考え方は同じです。ViteやNext.jsなどでlocalhost:3000やlocalhost:5173を使っている場合は、--urlに渡すポートを自分の開発サーバーに合わせます。 独自ドメインで固定URLにする 一時URLではなく、https://preview.example.com/のような固定URLでHugoプレビューを共有したい場合の手順です。 ドメイン準備 固定URL化するには、対象ドメインをCloudflareに追加し、DNSをCloudflareで管理できる状態にしておきます。 ...