显式代理无法与高级路由配合使用。这个问题通常应该在 11.1.5 版本中得到解决，但我们在 11.1.6 版本中仍然遇到了这个问题。

? The customer noticed that pinging the configured DNS server failed, but pinging other hosts worked as expected
? The customer noticed issues with the Secure Web Gateway Proxy when combined with advanced routing, particularly when attempting to access websites
? The customer observed that the issue was similar to a prior support case that was opened on an older software version, where the Advanced Routing support feature for Hybrid SWG was not implemented. Although the issue was reportedly resolved in version 11.1.5, the customer continued to experience it after upgrading to version 11.1.6.
? The customer confirmed that the issue was not related to the proxy's functionality but connected to the DNS resolving process
? The customer identified that the issue originated from the DNS configuration and the firewall's inability to reach the DNS servers
? The customer confirmed that the issue was not related to an incorrect listening interface for the DNS proxy, as the configured interface was deemed appropriate
? The Engineer observed that the firewall exhibited correct behavior when pinging other hosts but experienced a failure when attempting to ping the configured DNS servers.
? The Engineer observed that the firewall could not reach the DNS servers configured in the DNS proxy, including Google's DNS servers
? The Engineer confirmed the issue was independent of the explicit proxy configuration, authentication, decryption, and source NAT rules and their related settings, as these were configured correctly. This issue was related to a different vsys interface used in the service route for DNS. This difference in vsys and interface usage prevented the firewall from reaching the configured DNS proxy server.
? The Engineer observed that the issue was not replicable in the lab environment, indicating the issue was specific to their configuration and possibly tied to a service route mismatch. Upon analysis, it was confirmed that the issue was indeed related to a mismatch in the service route configuration between the customer's environment and the lab.
? The engineer observed that the issue was resolved after changing the service route configuration to utilize the `ae3.461` interface. After this change, the lab environment showed successful ping functionality.


**ERROR_LOGS**
> HTTP/1.1 503 Service Unavailable
> no healthy upstream
2025/03/23 00:06:38 listen udp v4 socket fd 22 on port 1053.

2025/03/23 00:06:38 listen udp v6 socket fd 23 on port 1053.

2025/04/04 17:20:03 2025-04-04 17:20:03.543 +0200 Error: pan_dnsproxyd_recv_dp_udp_cb(pan_dnsproxy_udp.c:308): [udp]: fd 22 from $ip to $ip process client failed! <<<<<<< fd 22 is the UDP v4 socket to 1053

• PANOS 11.1.6-hx
• PA-3410
• 高级路由
• 显式代理
• DNS代理
• 多 vsys，无vsys 间通信。
• DNS服务路由配置为使用来自另一个vsys 的接口。

调查显示，问题的根本原因在于DNS服务路由配置错误。服务路由配置为使用与 DNS 代理服务接口配置位置不同的vsys上的特定接口（“ae10.xx”），导致DNS代理无法生成针对DNS服务器的DNS查询。因此，防火墙无法解析从主机接口和客户端生成的DNS查询，从而导致网络流量在 DNS 代理中配置的 DNS 服务器中被黑洞拦截。

**补救计划**
1. 分析客户配置并将其与实验室配置进行比较，发现DNS的服务路由配置存在差异。在实验室环境中，服务路由使用“mgmt”接口进行配置；在客户环境中，它使用的是与配置DNS代理的vsys不同的“ae10.xx”。此配置不匹配被确定为根本原因。
2.修改DNS服务路由配置，以确保服务路由使用正确的vsys接口
3. 重新配置DNS的自定义目标服务路由以使用 `ae3.xx`接口，允许DNS代理接收来自主机接口和客户端的DNS请求。
4. 验证配置更改后在实验室环境中问题是否成功解决。
5. 实验室验证成功后，建议客户在其环境中实施相同的更改，并验证DNS解析问题是否已解决。这应涉及以下操作：

• 修改DNS的服务路由配置以使用适当的接口。
• 确保服务路由指向正确的vsys接口(ae3.xx)。
• 验证在同一个vsys上配置了DNS代理侦听接口。
• 测试DNS解析功能以确保其正常工作。
• 验证是否可以通过 eProxy 访问网站而不会出现其他问题。