#cloudflare
pnpm exec は cd を無視する。wrangler が本番サイトを古いビルドで上書きした
サブディレクトリに cd してから pnpm exec wrangler deploy を実行したら、Worker ではなくサイト本体が2日前のビルドで再デプロイされた。pnpm exec は最寄りの package.json があるディレクトリでコマンドを動かす。実測と、効いた対策。
Cloudflare が HTML に差し込むスクリプトは2種類ある。CSP はその片方を止めていた
beacon.min.js と Bot Fight Mode のインラインスクリプトは別物で、入ってくる経路も違う。 2 ゾーン 8 ホストを実測したら、ハッシュ方式の CSP が Cloudflare 自身の bot 検出を 何も言わないまま止めていた。
Cloudflare Workers の _headers が効かない — ルールは上書きされず積み重なる
マッチしたルールは全部適用され、同じヘッダーは追記される。CSP が2つ返る原因はこれで、 直すには `!` で消してから設定し直す。wrangler dev と本番で実測した。
CSP の nonce と hash:エッジで配る nonce は攻撃者のスクリプトにも付く
静的サイトで nonce を使いたいなら Worker を前に置いて HTMLRewriter で注入せよ、というのが 定番の助言。実際に組んで計測したら、注入されたインラインスクリプトにも同じ nonce が付き、 そのまま実行された。
Astro × Cloudflare の CMS 選び: Git ベースか、ヘッドレスか、そもそも無しか
Cloudflare Workers 上の静的 Astro サイトで CMS を選ぶ基準は「コンテンツがどこに住み、何がビルドを起動するか」に尽きます。content collections・Git ベース CMS・ホステッド型・D1 自作の4択を、実際に運用している構成から比較します。
Cloudflare Workers のリダイレクトは _redirects 1枚で足りる
Worker のコードは要りません。Workers static assets はプレーンテキストの _redirects ファイルで 301 を処理します。記法、splat、上限、そして危うく見落としかけた末尾スラッシュの罠。
静的な Astro サイトでブログ記事を予約公開する
サーバーも CMS も有料サービスも無しで、pubDate のフィルタと GitHub Actions の日次リビルドだけで予約公開を実現します。最初に必ず踏むタイムゾーンの罠も込みで。
Cloudflare Pages vs Workers(2026年版): 静的サイトはどちらに置くべきか
Pages は非推奨ではなく、機能が凍結された状態です。機能ごとの比較、料金、移行に実際にかかる作業、そして今も Pages のほうが勝っている2点をまとめました。
Google の SDK を使わずに Cloudflare Worker から GA4 Data API を叩く
Google の認証ライブラリは 23 パッケージを連れてきて、workerd 向けにはバンドルすら通りません。実際に必要なのは Web Crypto で RS256 の JWT を1つ署名することだけで、40行ほどで足ります。しかも鍵は Worker の外に出ません。
静的サイトに nonce は使えない: Astro + Cloudflare Workers の CSP
リクエストごとの nonce を発行できない以上、インラインスクリプトは hash で通すしかありません。ビルド出力のインライン script はページ数と同じだけ増えていきますが、必要な hash は3個で固定でした。その差を作っているのが、多くの CSP 解説が取り違えている一点です。
Astro を Cloudflare Workers にデプロイする(2026年版)
Cloudflare は新規プロジェクトの推奨先を Pages から Workers に切り替えました。静的な Astro サイトを Workers に載せる今のやり方を、独自ドメインの接続まで通しでまとめます。