Nested Wildcard(*) in URLs May Severely Affect Performance

Nested Wildcard(*) in URLs May Severely Affect Performance

Created On 09/26/18 13:51 PM - Last Modified 02/07/19 23:47 PM




Commit warning message

The following warning displays during a commit if a block or allow list contains an entry using multiple wildcards:

Warning: Nested wildcard(*) in URLs may severely impact performance. 
It is recommended to use a single wildcard to cover multiple tokens or a caret(^) to target a single token.




Reason of warning message


The asterisk (*) character is used as a wildcard token in the FQDN and path for custom URL filtering. The Palo Alto Networks firewall accepts multiple wildcard tokens in the field (ex. *.* and processes them appropriately.


However, as the number of wildcard tokens increases, the load on the system CPU increases exponentially (for example, *.*.*, or just *.* Therefore, we recommend to avoid Nested asterisk(*)  for practical usage.



Below is Wildcard usage and its example


Wildcard characterUsageExample
"*" asteriskmatch with one or more subdomains

The asterisk (*) wildcard does not respect the period (.) as a delimiter and will continue as a wildcard until a subdomain, domain or top level domain is matched.


sub1.*.*.com will match and *.* will match  However, this should be avoided as a best practice as nested asterisks can create a performance impact on the device.  


Instead, as a best practice you can use:  sub1.*.com or *  This will match 


"^" caretmatch with only one subdomains.

The caret (^) wildcard does respect the period (.) as a delimliter and will stop matching as a wildcard once a match has occurred.





are able to match with


Hence, ^ and sub1.^.com are not able to match with,  since "^" caret only matches with one subdomain.


If you'd like to replace "*" with "^", the following replacements are required: 


x.*.net is partically covered by the following:






Nested carets has a practical limit of 9 carets for the same DP resource usage reason above. 



Same limitation for Path

This limitation is applied to the pattern matching on path after FQDN. (i.e. http://<FQDN>/<path>), though we don't throw the commit warning message above for path.

Practical limit for nested asterisk in path is 2. But we highly recommend to use minimun number of asterisk for better DP utilization (CPU load/ Memory usage).


Side note:

Currently we have limitation that asterisk and caret should not be used in the same configuration. As mentioned above, caret cannot be fully replaced with asterisk.  Therefore replacing nested asterisks to single asterisk is considered best solution for most of customers practically. 

"2" for  nested asterisk in path and "9" for nested caret are practical number we suggest. Please consider to use lowest number as possible for better DP load (i.e. lower platform).



  • Print
  • Copy Link

Choose Language