버전: 4.6.1

트리거 규칙 설정

"트리거 규칙 설정"은 특정 URL 조건에 따라 대기실/차단실을 노출할 규칙을 설정할 수 있는 구성으로, 트래픽 제어가 활성화되어야 하는 시점에 대한 세밀한 제어를 제공합니다. 이 기능은 URL 트리거 통합(UTI)에서만 의미가 있습니다.

Trigger Rule Setting Console

개요

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 Type: 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: "최소한 하나의 조건이 참이어야 함" - 어떤 조건이든 트래픽 제어를 트리거할 수 있음

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 Type

URL 구성 요소를 비교하는 방법:

Match Type	작동 방식	예시
Exists	"이 부분이 존재하는가?"	페이지에 경로가 있는가?
Equals	"이것이 정확히 동일한가?"	경로가 정확히 `/event`여야 함
Contains	"이것이 이 텍스트를 포함하는가?"	도메인이 `api`를 포함
StartsWith	"이것이 이것으로 시작하는가?"	경로가 `/mobile`로 시작
EndsWith	"이것이 이것으로 끝나는가?"	경로가 `.html`로 끝남

Value

URL에서 찾아 일치시킬 특정 텍스트를 의미합니다.

대소문자 구분 (Aa)

대문자에 대해 신경 쓸지 여부:

체크 안 됨: "VIP"와 "vip"가 동일하게 처리됨
체크됨: "VIP"와 "vip"가 다르게 처리됨

구성 프로세스

1단계: 트리거 규칙 설정 액세스

NetFUNNEL에서 기본 제어 세그먼트로 이동
"트리거 규칙 설정" 클릭
중요: UTI를 사용하고 있는지 확인 - 트리거 규칙은 URL 트리거 통합에서만 의미가 있음

2단계: 첫 번째 조건 생성

검사할 항목 선택: Validator에서 "URL" 선택
검사할 부분 선택: Component에서 Domain, Path 또는 URL 선택
엄격함 정도 결정: Match Type 선택 (Equals, Contains, StartsWith 등)
찾을 항목 기록: Value에 특정 값 입력
정상 또는 역 선택: Negate에서 "Does" 또는 "Does not" 선택 (정상 조건 또는 예외 조건)
대문자에 대해 결정: 대소문자 구분에서 조건에 대해 대소문자 구분이 중요한지 확인

3단계: 규칙 테스트

라이브 전에 규칙을 테스트하여 예상대로 작동하는지 확인하세요:

콘솔에 테스트 URL 입력 (다른 메뉴 항목 테스트와 같음)
규칙이 올바르게 적용되는지 확인
필요시 설정 조정

4단계: 여러 조건 추가 (선택 사항)

더 복잡한 로직이 필요한 경우:

추가 조건 추가
결합하기 위해 AND/OR 선택
결합된 동작 테스트

현재 제한 사항

쿼리 문자열 필터링은 현재 트리거 규칙에서 지원되지 않습니다. URL 경로, 도메인 또는 전체 URL에 대해서만 일치시킬 수 있습니다.

쿼리 문자열에 대한 해결 방법: 특정 쿼리 매개변수가 있는 페이지를 보호해야 하는 경우, 브라우저에서 쿼리 문자열을 포함한 전체 URL을 복사하고 URL 정확 일치를 사용하세요.

이 제한 사항은 향후 업데이트에서 해결될 수 있습니다.

일반적인 사용 사례

가장 일반적인 시나리오와 일반적인 구성은 다음과 같습니다:

시나리오	Component	Match Type	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 보호

모범 사례

트리거 규칙을 설정할 때는 간단하게 시작하고 점진적으로 복잡성을 구축하는 것이 중요합니다. 한 번에 모든 것을 구성하려고 시도할 경우 예상치 못한 동작으로 이어질 수 있습니다.

간단하게 시작한 다음 확장

가장 좋은 접근 방식은 가장 중요한 페이지로 시작하고 점진적으로 더 많은 조건을 추가하는 것입니다. 예를 들어, 전자상거래 사이트는 /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으로 시작"과 같이 구체적으로 지정하여 필요한 영역만 보호하세요.

대소문자 구분 혼란은 또 다른 일반적인 문제입니다. 특정 요구 사항이 없는 한, 사용자가 사이트로 이동하는 방식에 따라 /Event와 /event에 액세스할 수 있으므로 대소문자 구분을 체크 안 됨 상태로 유지하세요.

매개변수 변형을 테스트하지 않을 경우 /product?id=123은 작동하지만 /product?category=electronics는 작동하지 않는 문제를 일으킬 수 있습니다. 항상 다른 매개변수 조합으로 URL을 테스트하여 조건이 예상대로 작동하는지 확인하세요.

팁

"규칙 1"과 같은 일반적인 이름 대신 조건에 대해 설명적인 이름을 사용하세요. "체크아웃 보호" 또는 "플래시 세일 보호"와 같은 이름은 관리가 훨씬 쉬워지며, 특히 여러 조건이 있을 때 유용합니다.

설정을 보수적으로 시작하고 점진적으로 증가시키세요. 제한을 증가시키는 것이 시스템 과부하를 처리하는 것보다 훨씬 쉽고, 이 접근 방식은 특정 트래픽 패턴에 대한 최적의 지점을 찾는 데 도움이 됩니다.

마지막으로, 조건이 활성화되어 있을 때 항상 서버 메트릭(CPU, 메모리, 응답 시간)을 모니터링하여 추가 문제를 일으키는 대신 실제로 시스템에 도움이 되는지 확인하세요.

고급 구성 옵션 및 통합 세부 사항은 기본 제어 세그먼트 개요 및 기본 설정 문서를 참조하세요.

개요​

작동 방식​

트리거 규칙 처리 흐름​

규칙 구성 요소​

트리거 규칙 구조​

논리 연산자​

Validator​

Component​

Negate​

Match Type​

Value​

대소문자 구분 (Aa)​

구성 프로세스​

1단계: 트리거 규칙 설정 액세스​

2단계: 첫 번째 조건 생성​

3단계: 규칙 테스트​

4단계: 여러 조건 추가 (선택 사항)​

일반적인 사용 사례​

모범 사례​

간단하게 시작한 다음 확장​

테스트 전략​

일반적인 실수​

팁​

개요