トリガールール設定

「トリガールール設定」は、特定のURL条件に応じて待合室/ブロックルームを表示するルールを設定できる構成で、トラフィック制御が有効化されるべきタイミングに関する細かい制御を提供します。この機能はURLトリガー統合（UTI）でのみ意味があります。

概要

URLトリガー統合（UTI）では、ウェブサイトのどこにトラフィック制御を適用するかを定義する必要があります。コードベース統合（CBI）がnfStart()およびnfStop()関数を使用して特定のコードセグメントをラップするのに対し、UTIはURLベースのルールを使用して、どのページがトラフィック制御をトリガーすべきかを決定します。

トリガールールは、根本的な質問に答える核心構成です：「どのリクエストがトラフィック制御を通過すべきか？」

重要: ページリクエストのみ

UTIはページリクエストにのみ適用され、API呼び出しには適用されません。ユーザーがページに移動するとき（リンククリックまたはURL入力など）、UTIはアクセスを制御できます。しかし、AJAX呼び出し、APIリクエスト、またはその他のバックグラウンドリクエストは、トリガールールの影響を受けません。

APIエンドポイントを保護する必要がある場合、代わりにnfStart()およびnfStop()関数を使用するコードベース統合（CBI）を使用してください。

動作方法

誰かがウェブサイトを訪問すると、NetFUNNELはアクセスしようとするURLを検査し、トリガールールと比較します：

• URLがルールと一致する場合: 訪問者がそのページにアクセスする前に待合室に移動
• URLがどのルールとも一致しない場合: 訪問者がページに直接移動

これにより、トラフィック制御で保護すべきページ、パス、またはドメインを正確に定義する複数のルールを設定できます。

トリガールール処理フロー

トリガールール使用タイミング

トリガールールはURLトリガー統合（UTI）でのみ意味があります。コードベース統合（CBI）を使用する場合、nfStart()およびnfStop()関数を使用してコードから直接トラフィックを制御するため、トリガールールは必要ありません。

このように考えてください：UTIを使用すると、ドア（URLレベル）でトラフィックを制御するため、どのページに待機が必要かを決定するルールが必要です。CBIを使用すると、建物内部（コードレベル）でトラフィックを制御するため、保護すべきものを既に正確に知っています。

ルール構成要素

トリガールールは、論理演算子（AND/OR）を使用して結合された複数の条件で構成されます。各条件はURLで見つける内容を指定し、論理演算子はこれらの条件が一緒に動作する方法を決定します。

トリガールール構造

トリガールール
└── 条件1
    ├── Validator: URL
    ├── Component: Path | Domain | URL
    ├── Match: Equals | Contains | StartsWith | EndsWith | Exists
    ├── Value: 一致させる特定のテキスト
    ├── Negate: Does | Does not
    └── 大文字小文字の区別: チェック済み | チェックなし
    ↓
    [AND | OR]  ← 論理演算子
    ↓
    条件2（同じ構造）
    ↓
    [AND | OR]  ← 論理演算子（条件がさらにある場合）
    ↓
    条件N...（同じ構造）

例: AND演算子を使用する2つの条件があるトリガールール

• 条件1: Pathが/checkoutと等しい
• AND ← 論理演算子
• 条件2: Domainがshop.example.comと等しい
• 結果: shop.example.comの/checkoutページのみがトラフィック制御をトリガー

論理演算子

複数の条件がある場合、これは条件が一緒に動作する方法を定義します：

• AND: 「すべての条件が真でなければならない」 - トラフィック制御が適用されるには、すべての条件が一致する必要がある
• OR: 「少なくとも1つの条件が真でなければならない」 - どの条件でもトラフィック制御をトリガーできる

Validator

検査するリクエスト属性のタイプ：

• URL: 現在唯一のオプション - 誰かがアクセスしようとするウェブアドレスを検査
• 将来のオプションには、Header、Cookie、およびその他のリクエスト属性が含まれる可能性がある

Component

検査するURLの部分：

Component	検査内容	例
URL	完全なウェブアドレス	https://example.com/page?id=123
Domain	ウェブサイト名のみ	example.com、www.example.com
Path	特定のページパス	/page、/api/users

Negate

ルールを正常に適用するか、逆に適用するか：

• Does: 「これが真のときにトラフィック制御を適用」（正常）
• Does not: 「これが偽のときにトラフィック制御を適用」（逆） - 「管理者ページを除くすべてのページにトラフィック制御を適用」と同じ

Match

URL構成要素を比較する方法：

Match	動作方法	例
Exists	「この部分が存在するか？」	ページにパスがあるか？
Equals	「これが正確に同じか？」	パスが正確に/eventでなければならない
Contains	「これがこのテキストを含むか？」	ドメインがapiを含む
StartsWith	「これがこれで始まるか？」	パスが/mobileで始まる
EndsWith	「これがこれで終わるか？」	パスが.htmlで終わる

Value

一致させる特定のテキスト。これはURLで探しているものです。

大文字小文字の区別（Aa）

大文字について気にするかどうか：

• チェックなし: 「VIP」と「vip」が同じように処理される
• チェック済み: 「VIP」と「vip」が異なるように処理される

構成プロセス

トリガールール設定は、レストランのための特別なメニューシステムを作成するようなものです。ステップごとに見ていきましょう：

ステップ1: トリガールール設定にアクセス

1. NetFUNNELで基本制御セグメントに移動
2. 「トリガールール設定」をクリック
3. 重要: UTIを使用していることを確認 - トリガールールはURLトリガー統合でのみ意味がある

ステップ2: 最初の条件を作成

これをメニューに特別なセクションを追加することと考えてください：

1. 検査する項目を選択: Validatorで「URL」を選択（誰かが望むメニューセクションを確認するようなもの）
2. 検査する部分を選択: ComponentでDomain、Path、またはURLを選択（レストラン名のみを確認するのと、完全なメニュー項目を確認するのの違い）
3. 厳密さの程度を決定: Match Typeを選択（Equals、Contains、StartsWithなど）
4. 探す項目を記録: Valueに特定の値を入力（特別メニューの「VIPラウンジ」のようなもの）
5. 正常または逆を選択: Negateで「Does」または「Does not」を選択（正常条件または例外条件）
6. 大文字について決定: 大文字小文字の区別で、条件について大文字小文字の区別が重要かどうかを確認

ステップ3: ルールをテスト

ライブ前にルールをテストして、期待通りに動作するか確認してください：

1. コンソールにテストURLを入力（他のメニュー項目をテストするようなもの）
2. ルールが正しく適用されるか確認
3. 必要に応じて設定を調整

ステップ4: 複数の条件を追加（オプション）

より複雑なロジックが必要な場合：

1. 追加条件を追加
2. 結合するためにAND/ORを選択（「VIPラウンジ AND 特別イベント」のようなもの）
3. 結合された動作をテスト

現在の制限事項

クエリ文字列フィルタリングは、現在トリガールールでサポートされていません。URLパス、ドメイン、または完全なURLについてのみ一致させることができます。

クエリ文字列の回避策: 特定のクエリパラメータがあるページを保護する必要がある場合、ブラウザでクエリ文字列を含む完全なURLをコピーし、URL完全一致を使用してください。

この制限事項は、将来のアップデートで解決される可能性があります。

一般的な使用事例

最も一般的なシナリオと一般的な構成は以下のとおりです：

シナリオ	Component	Match	Value	論理演算子	例
特定のページを保護	Path	Equals	/checkout	-	チェックアウトページのみを保護
ページグループを保護	Path	StartsWith	/event	-	すべてのイベントページを保護
複数のページ	Path	Equals	/checkout、/flash-sale、/limited-edition	OR	複数の特定ページを保護
ドメイン別保護	Domain	Equals	shop.example.com	-	shopサブドメインのみを保護
結合された条件	Path + Domain	Equals	/checkout + shop.example.com	AND	shopドメインのチェックアウトのみを保護
完全なURLを保護	URL	Equals	https://example.com/checkout?step=payment	-	クエリ文字列がある特定のURLを保護

ベストプラクティス

トリガールールを設定する際は、シンプルに始めて段階的に複雑さを構築することが重要です。多くのユーザーが一度にすべてを構成しようと試みる間違いを犯し、これはしばしば混乱と予期しない動作につながります。

シンプルに始めてから拡張

最良のアプローチは、最も重要なページから始めて、段階的により多くの条件を追加することです。例えば、Eコマースサイトは/checkoutページのみを保護することから始め、数週間トラフィックパターンをモニタリングした後、/flash-saleおよび/limited-edition条件を追加できます。

この段階的アプローチは、複雑さを追加する前に、トリガールールが特定のトラフィックパターンとどのように動作するかを理解するのに役立ちます。

テスト戦略

ライブ前に常に条件を徹底的にテストしてください。進入許容数を0に設定して待合室が正しく表示されることを確認し、その後、異なる大文字小文字、パラメータ、および形式を含むさまざまなURLバリエーションでテストしてください。

良いテストアプローチには以下が含まれます：

• 完全一致テスト: https://example.com/event（トリガーされるべき）
• 大文字小文字バリエーションテスト: https://example.com/EVENT（大文字小文字の区別がない場合はトリガーされるべき）
• パラメータでテスト: https://example.com/event?id=123（トリガーされるべき）
• エッジケーステスト: https://example.com/events（等しいではトリガーされないべき）

避けるべき一般的な間違い

過度に広範囲な条件は頻繁な問題です。「Pathが/で始まる」を使用すると、サイトのすべてを保護することになり、これはほとんど望ましいものではありません。代わりに「Pathが/checkoutで始まる」のように具体的に指定して、必要な領域のみを保護してください。

大文字小文字の区別の混乱は、もう1つの一般的な問題です。特定の要件がない限り、ユーザーがサイトに移動する方法に応じて/Eventと/eventにアクセスできるため、大文字小文字の区別をチェックなしの状態に保ってください。

パラメータバリエーションをテストしないことは、/product?id=123は動作するが/product?category=electronicsは動作しない問題を引き起こす可能性があります。常に異なるパラメータの組み合わせでURLをテストして、条件が期待通りに動作するか確認してください。

専門家のヒント

「ルール1」のような一般的な名前の代わりに、条件について説明的な名前を使用してください。「チェックアウト保護」または「フラッシュセール保護」のような名前は、管理がはるかに簡単になり、特に複数の条件がある場合に便利です。

設定を保守的に始めて段階的に増加させてください。制限を増やすことは、システム過負荷を処理するよりもはるかに簡単で、このアプローチは特定のトラフィックパターンに対する最適なポイントを見つけるのに役立ちます。

最後に、条件が有効化されているときは常にサーバーメトリック（CPU、メモリ、応答時間）をモニタリングして、追加の問題を引き起こすのではなく、実際にシステムに役立つことを確認してください。

高度な構成オプションおよび統合の詳細については、基本制御セグメント概要および基本設定ドキュメントを参照してください。