Support Center > Search Results > SecureKnowledge Details
Latency on HTTPS traffic when using URL Filtering Technical Level
  • High latency for HTTPS traffic when using URL Filtering.
  • Web Categorization mode is set to Hold. If you set it to background then the latency disappears.
  • All categorization is failing due to "could not connect to".
  • Fail-open causes high latency. Fail-close causes all web traffic to fail.
  • Running: "curl_cli" on the Security Gateway shows that the domain can be resolved successfully.
  • When reviewing the Security Gateway's DNS activity in packet captures, there is a mixture of successful DNS resolutions and DNS replies stating "no such name A".
  • Running: rad_admin install under RAD debugs (sk92743) will show the following output in rad.elg:
    Sock_Input: got a UDP packet
    Sock_Input: ParseResponce result is r_name_error

    CRadHttpRequest::getLocation: [INFO] enter to ...
    CRadHttpRequest::getLocation: [INFO] Host or Port are zero, trying to retrieve them again
    CRadFetcher::fetch: [INFO] IPv4:0
    CRadFetcher::fetch: [WARN] Empty host. The resolution failed or not completed yet...

RAD resolves on policy installation and holds the IP address for categorization.

If the first DNS reply that the RAD daemon receives when querying is "no such name A", it considers this a failure and ignores further DNS replies even if the latter were successful. As a result, future URL categorization attempts will fail because RAD does not have an IP address registered for


Note: RAD will query all DNS servers in /etc/resolv.conf. This can include other DNS servers that were not configured in clish. Doing packet captures only for the DNS servers configured in clish or in the webUI may be misleading.

Note: To view this solution you need to Sign In .