Conversation
RoRoJ
added
type: new content
nerda-codes
reviewed
Feb 4, 2026
|
|
||
|
|
||
| - Traffic is tested against the first rule in the list first: any matching traffic is directly routed to the specified WAF policy/backend. | ||
| - Traffic that didn't match the first rule is then tested against the second rule. If it matches, the routing rule is directly applied. |
Collaborator
There was a problem hiding this comment.
Suggested change
| - Traffic that didn't match the first rule is then tested against the second rule. If it matches, the routing rule is directly applied. | |
| - Traffic that did not match the first rule is then tested against the second rule. If it matches, the routing rule is directly applied. |
| - Traffic is tested against the first rule in the list first: any matching traffic is directly routed to the specified WAF policy/backend. | ||
| - Traffic that didn't match the first rule is then tested against the second rule. If it matches, the routing rule is directly applied. | ||
| - ... and so on, until unmatched traffic arrives at the end of the list of rules. | ||
| - The last rule is necessarily the default rule, which dictates where to route traffic that didn't match any other rule. |
Collaborator
There was a problem hiding this comment.
Suggested change
| - The last rule is necessarily the default rule, which dictates where to route traffic that didn't match any other rule. | |
| - The last rule is necessarily the default rule, which dictates where to route traffic that did not match any other rule. |
| - ... and so on, until unmatched traffic arrives at the end of the list of rules. | ||
| - The last rule is necessarily the default rule, which dictates where to route traffic that didn't match any other rule. | ||
|
|
||
| Therefore, when creating route rules, remember to order them from most specific to most general. This ensures that precise, high-priority routing decisions are evaluated first, while broader or fallback rules are applied only to traffic that doesn't match the earlier conditions. |
Collaborator
There was a problem hiding this comment.
Suggested change
| Therefore, when creating route rules, remember to order them from most specific to most general. This ensures that precise, high-priority routing decisions are evaluated first, while broader or fallback rules are applied only to traffic that doesn't match the earlier conditions. | |
| Therefore, when creating route rules, remember to order them from most specific to most general. This ensures that precise, high-priority routing decisions are evaluated first, while broader or fallback rules are applied only to traffic that does not match the earlier conditions. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Add a page of doc for Edge Services Multi-Backend/Routing. This is to be published when routing/multi-backend becomes available on the API.