---
title: "Explicit proxy"
canonical: "https://docs.aryaka.com/space/KNOW/1330151441/Explicit%20proxy"
format: markdown
---
An explicit proxy intercepts and proxies HTTP connections from clients to destination servers on their behalf. It enables remote users to connect to Aryaka’s POPs and provides granular visibility and control over HTTP traffic destined for the internet. Aryaka’s explicit proxy integrates with other security solutions within the Aryaka SASE platform, delivering a comprehensive security posture.  This document provides an overview of the Aryaka explicit proxy offering. To get started configuring your service in MyAryaka, see the  Configure explicit proxy domains  topic.  Prerequisites Remote user regions (Global and Mainland China) for either of the following products include explicit proxy: SmartSecure NGFW-SWG Unified SASE Use cases The following are the primary use cases for explicit proxy: Secure unmanaged and “bring your own” devices.  Enforce SASE policies on devices where installing an agent is not possible or not allowed. This allows you to secure contractor, partner, and temporary workforce internet access by extending SASE inspection to personal devices without granting network access, providing browser-based enforcement that does not require client installation.  Secure third-party and vendor internet access.  Apply URL filtering, CASB, DLP, and threat prevention to vendors without giving VPN or private network access. This allows you to enforce identity-based internet policies without site connectivity, providing internet security without expanding the attack surface. Rapid rollout for distributed users.  Use PAC/WPAD to enable security for remote users. There is no OS dependency and onboarding is faster, compared to agent-based deployment. Internet breakout with centralized policy enforcement.  Browser traffic is routed to Aryaka POPs for inspection, allowing security policies to be applied consistently across distributed users. You can view centralized logs and reports in MyAryaka. Identity-based web security for non-VPN users.  Apply user and user group-based web controls without VPN connectivity. This allows you to enforce acceptable use policies for internet traffic only and bridges the gap between unmanaged remote users and full ZTNA onboarding. Technical details Aryaka offers agent-based and agent-less solutions that allow remote users to access Aryaka’s POPs.  Aryaka’s ZTNA offering is an agent-based remote user solution—an Aryaka Agent is installed on your remote users’ devices to control their connection to Aryaka POPs. Users can then either connect to one of your network’s sites or locally break out to the internet. Explicit proxy is an agent-less solution. Instead of installing an agent on user devices, you push a PAC file to client web browsers, which redirects internet traffic to the proxy server on the closest POP. When the proxy intercepts traffic, it masks the client’s source IP and presents the proxy’s source IP to the destination server. The traffic is then routed through that POP, where it locally breaks out to the internet. These users do not have access to your sites’ networks. PAC files When using explicit proxy, the internet browser must be instructed on how to route traffic to the proxy server. You can do this by directly pushing the proxy URL to your client machines or using a PAC file. PAC files define the specific domains for which browser-based traffic should be routed to Aryaka POPs for inspection. If you use a PAC file, you can either create and store the PAC file locally or with Aryaka.  When Aryaka hosts your PAC files, you are provided with a URL to access the server where your files are hosted. You should provide this URL to the Web Proxy Auto-Discovery (WPAD) tool used by your organization. Then, when an explicit proxy remote user opens a web browser, the browser requests the PAC file from the specified URL and reads the PAC file to determine what traffic to intercept and forward to the proxy instance.  Version control MyAryaka provides version control to allow you to efficiently manage your PAC files. The PAC files page displays a list of configured PAC files and includes each file's URL, the proxies it is applied to, and it’s current version. Click  View Audit Logs  to view a record of modifications to your PAC files. If you select a proxy, you can view the content of the file and it’s version history (up to five previous versions). If you select a previous version of the file you can compare it to another version in the history.  Users are limited to uploading a maximum of 10 PAC files. Each PAC file may not exceed 1 MB. PAC file template You can use the following PAC file template to create a new PAC file for explicit proxy: /**
 * This file uses the standard PAC file format to determine the proxy settings for network requests.
 * The main function FindProxyForURL(url, host) is executed for each request to determine the appropriate proxy.
 *
 * @param {string} url - The URL being accessed.
 * @param {string} host - The hostname of the URL being accessed.
 * @returns {string} - The proxy configuration for the given URL/host.
 */
function FindProxyForURL(url, host) {
/**
    // Route specific domains through the proxy
    if (shExpMatch(url, "*.microsoft.com/*")) {
        return "PROXY proxyname.aryaka.com:8080";
    }
    // Route specific URLs through the proxy
    if (shExpMatch(url, "http://*.facebook.com/*")) {
        return "PROXY proxyname.aryaka.com:8080";
    }
    // Route specific subnets through the proxy
    if (isInNet(host, "172.19.168.0", "255.255.255.0")) {
        return "DIRECT";
    }
   // Route specific subnets through the proxy
    if (url.substring(0, 4) === "ftp:") {
        return "PROXY proxyname.aryaka.com:8080";
    }
    // Use return "DIRECT" to skip the proxy.
    if (shExpMatch(url, "*.aryaka.com/*")) {
        return "DIRECT";
    }
    // To handle specific DNS domains
    if (dnsDomainIs(host, ".aryaka.com")) {
        return "DIRECT";
    }    
    */
   // Default to using a proxy
    return "PROXY proxyname.aryaka.com:8080";
} Best practices Enforce least privilege access.  Allow only authorized remote users to access your network resources. Test new rules . Test rules you want to add to your configuration in a safe environment before applying them to your network. Monitor network traffic.  Regularly audit your security logs to ensure your security rules are operating as expected. If you discover that you need to block a certain type of traffic or create a rule exception due to a false positive, you can modify the rule or create additional rules as needed. See the  Security  topic for general best practices for managing your SASE service. In this topic Related topics Configure explicit proxy domains UZTNA regions