知っておくべき問題

以下は、Cloudflare Workersを使用する際に注意すべき既知のバグや問題です。

ルートの特異性

• ルートの特異性を定義する際、パターンの末尾にある /* が期待通りに機能しない場合があります。

同じゾーンにデプロイされた2つの異なるWorkersを考えてみましょう。Worker Aは example.com/images/* ルートに割り当てられ、Worker Bは example.com/images* ルートパターンが与えられています。これらが設定された状態で、以下のURLがどのように解決されるかを示します：

// (A) example.com/images/*
// (B) example.com/images*

"example.com/images"
// -> B
"example.com/images123"
// -> B
"example.com/images/hello"
// -> B

すべての例がWorker Bをトリガーすることに気付くでしょう。これは、予期しない動作を示す最終例も含まれています。

サブドメインにワイルドカードを追加する場合、以下のURLがどのように解決されるかを示します：

// (A) *.example.com/a
// (B) a.example.com/*

"a.example.com/a"
// -> B

wrangler dev

• wrangler dev --remote を実行すると、すべての送信リクエストに cf-workers-preview-token ヘッダーが付与され、Cloudflareはこれをプレビューリクエストとして認識します。これはCloudflareネットワーク全体に適用されるため、他のCloudflareゾーンへのHTTPリクエストは現在セキュリティ上の理由から無視されます。回避策を有効にするには、以下のコードをWorkerスクリプトに挿入してください：

const request = new Request(url, incomingRequest);
request.headers.delete('cf-workers-preview-token');
return await fetch(request);

CNAME設定におけるFetch API

Workerから fetch() を使用してサブリクエストを行うと、CloudflareのDNSリゾルバーが使用されます。ゾーンが Partial (CNAME) setup の場合、Workerが解決する必要のあるすべてのホスト名には、CloudflareのDNS設定に専用のDNSエントリが必要です。そうでない場合、Fetch API呼び出しはステータスコード 530 (1016) で失敗します。

Cloudflare DNSにDNSレコードが不足している設定

example.com

// 権威DNSのDNSレコード: sub1.example.com, sub2.example.com, ...
// Cloudflare DNSのDNSレコード: sub1.example.com

"sub1.example.com/"
// -> Fetch APIで解決可能
"sub2.example.com/"
// -> Fetch APIで解決不可、530ステータスコードに至る

Cloudflare DNSに sub2.example.com を追加した後

example.com

// 権威DNSのDNSレコード: sub1.example.com, sub2.example.com, ...
// Cloudflare DNSのDNSレコード: sub1.example.com, sub2.example.com

"sub1.example.com/"
// -> Fetch APIで解決可能
"sub2.example.com/"
// -> Fetch APIで解決可能

カスタムポート

Workersのサブリクエストでは、Workerがデプロイされると、カスタムポートは無視され、リクエストはスキームのデフォルトポート（HTTPSの場合は 443）に送信されます。ローカルでWorkerを開発する場合や、Cloudflareダッシュボード内でQuick Editを使用する場合は、カスタムポートが尊重され、許可されます。

例えば：

await fetch('https://example.com:1234/foo')

は次のものと同等です：

await fetch('https://example.com/foo')

IPアドレスへのFetch

Workersのサブリクエストでは、リクエストはURLに対してのみ行うことができ、IPアドレスに直接リクエストを送ることはできません。この制限を克服するには、ゾーンにAまたはAAAAの名前レコードを追加 ↗し、そのリソースを取得します。

例えば、ゾーン example.com に server という名前のタイプ A のレコードを作成し、値を 192.0.2.1 とし、次のように使用します：

await fetch('http://server.example.com')

次のように使用しないでください：

await fetch('http://192.0.2.1')