A laptop in the office can't reach a vendor portal, the same laptop at home reaches it fine, and the firewall log shows nothing blocked. Nine times out of ten the thing in the middle is a proxy, and the technician who understands what it does fixes the ticket in minutes. This guide explains what a proxy server is, the three kinds you'll meet at work, where PAC files fit, and how to set one up without breaking Microsoft 365.
TL;DR
- A proxy server is a machine that makes requests on behalf of another machine. The HTTP standard calls it "a message-forwarding agent that is chosen by the client".
- A forward proxy sits in front of users and faces the internet. A reverse proxy sits in front of servers and faces the users. A transparent proxy is a forward proxy nobody configured the client for.
- Businesses run proxies for four reasons: filtering what users reach, logging who reached what, caching, and hiding internal addresses.
- A PAC file is a small JavaScript function that tells each browser which proxy to use for which URL. It is how you send some traffic through the proxy and the rest straight out.
- Proxies and VPNs are different tools. A proxy works per application and per URL; a VPN moves the whole device onto another network.
- Microsoft's guidance since 2026 is to send Microsoft 365 traffic past the proxy, not through it.
What a Proxy Server Is
A proxy server is a computer that sends requests for you. Your browser asks the proxy for a page, the proxy asks the website, the website answers the proxy, and the proxy hands the answer back. The website sees the proxy's address, not yours.
The HTTP specification (RFC 9110, section 3.7) defines three kinds of intermediary: a proxy, a gateway and a tunnel. A proxy is "a message-forwarding agent that is chosen by the client, usually via local configuration rules". The phrase that matters is "chosen by the client". Your device is told to use the proxy, and it does so on purpose.
That same section explains why organisations bother. Proxies group a company's web requests "through a common intermediary for the sake of security services, annotation services, or shared caching". Translated: one chokepoint where you can inspect, log, block and cache.
A proxy is not a firewall, although the two often live in the same box. A stateful firewall decides whether a connection may exist. A proxy takes part in the conversation, reads the request, and can change it or refuse it on content grounds.
How a Proxy Handles a Request
For plain HTTP the flow is simple. The browser opens a connection to the proxy instead of the website and sends the full URL. The proxy fetches it, checks policy, serves it from cache if it can, and returns the response.
HTTPS changes the picture, because the proxy can't read an encrypted request. RFC 9110 gives proxies a method for this: CONNECT. The browser sends CONNECT vendor.example.com:443 to the proxy, the proxy opens a TCP connection to that host and port, and then switches to "blind forwarding of data, in both directions". Encrypted bytes pass through. The proxy sees the hostname and port, and nothing inside.
That blindness is why "SSL inspection" exists. An inspecting proxy ends the TLS session on itself, decrypts, inspects, then re-encrypts to the destination with its own certificate. Every client must trust that certificate, or every HTTPS site breaks at once. If you have ever pushed a root certificate to a fleet so the browser warnings would stop, you have met this.
The proxy can also add headers. X-Forwarded-For carries the original client address so the next hop knows who asked. Via records that a proxy was on the path. Both are useful in logs and both are worth knowing when a web app behaves differently from behind the proxy.
Forward, Reverse and Transparent Proxies
All three are "a thing in the middle", and they solve different problems. The quickest way to tell them apart is to ask which side configured it and which side it protects.
| Type | Who configured it | Who it faces | Typical job |
|---|---|---|---|
| Forward proxy | The client (browser, OS, PAC file) | The internet, on behalf of users | Web filtering, logging, caching, egress control |
| Reverse proxy | The server owner | Users, on behalf of servers | TLS termination, load balancing, hiding backends |
| Transparent proxy | Nobody on the client | The internet, by intercepting traffic | Filtering on guest and captive networks |
Forward Proxy
A forward proxy is the classic corporate web proxy. Users' browsers point at it, every outbound web request passes through it, and policy is applied on the way out. It knows which user asked for which URL, so it can block categories, require authentication and keep logs that name a person rather than an IP.
The ticket at the top of this post is a forward-proxy ticket. The office browser is sending the vendor portal through the proxy, which blocks it or fails to resolve it. At home there is no proxy, so it works.
Reverse Proxy
A reverse proxy is the mirror image. RFC 9110 calls it a "gateway": an intermediary that "acts as an origin server for the outbound connection but translates received requests and forwards them inbound to another server or servers". Users think they are talking to the website. They are talking to the reverse proxy, which passes the request to whichever backend should handle it.
Gateways, the RFC notes, are "used to encapsulate legacy or untrusted information services, to improve server performance through 'accelerator' caching, and to enable partitioning or load balancing of HTTP services across multiple machines". In practice that means one public address and certificate in front of several internal servers. NGINX, HAProxy, Apache with mod_proxy, Traefik and Caddy all do this, and every content delivery network is a reverse proxy at scale.
If your client runs an on-prem web app that has to be reachable from outside, the reverse proxy is what you put in front of it instead of a bare port forward to the application server.
Transparent Proxy
A transparent proxy, which RFC 9110 also calls an interception proxy, "differs from an HTTP proxy because it is not chosen by the client. Instead, an interception proxy filters or redirects outgoing TCP port 80 packets". The router or firewall quietly diverts web traffic to the proxy. The browser believes it is talking straight to the site.
The RFC says where you'll find them: "on public network access points, as a means of enforcing account subscription prior to allowing use of non-local Internet services, and within corporate firewalls to enforce network usage policies". That is the hotel login page and the school content filter.
The Squid project, which has shipped interception proxying for decades, lists the costs. Interception "breaks TCP/IP standards because user agents think they are talking directly to the origin server". Proxy authentication does not work, because the browser doesn't know there is a proxy to authenticate to. And the proxy sees every user as its own IP address, so per-user logging is gone. Transparent proxies are convenient. They are also the reason a client's web filter can't tell you which staff member visited what.
What Businesses Use Proxies For
Strip away the vendor language and a forward proxy does four jobs.
Filtering. Block categories (gambling, adult, known malware hosts), block specific domains, allow only a list. Modern filtering has largely moved to DNS and to the endpoint, which is why DNS filtering now covers what a proxy used to. A proxy still wins where you need to filter by URL path or by content rather than by hostname.
Logging. Who went where, when, and how much they downloaded. With authentication turned on, the log names the user. Compliance teams and incident responders both lean on this.
Caching. Twenty people downloading the same Windows update or the same video get it from the proxy's cache after the first fetch. This mattered more when office bandwidth was scarce, and it still matters on sites with thin links.
Hiding the inside. The internet sees the proxy's address, not the workstation's. For a reverse proxy this flips: the internet sees one hardened front door, not the application servers behind it.
There is a fifth use that belongs in a different post. Residential and datacenter proxies sold for scraping, ad verification and geo-testing are a consumer-facing market with its own vocabulary, and they are what a lot of the search results for this topic are about. If you landed here from one of those, the mechanics are the same; the business case is not.
Proxy vs VPN
The two get confused because both "hide your IP". The difference is scope.
A proxy works per application and, with a PAC file, per URL. The browser uses it, the mail client may not, a PowerShell script almost certainly doesn't unless you tell it to. Nothing on the device is encrypted by the proxy itself.
A VPN moves the whole device onto another network. Every packet from every application goes through the tunnel, encrypted. A remote worker on a VPN is, for most purposes, sitting in the office. If that is the problem you are solving, the remote worker playbook covers the trade-offs.
They stack. A laptop on the company VPN often also picks up the company proxy, because the VPN delivers the PAC file or because Group Policy applies once the device can see a domain controller. That is the source of a well-known ticket class: the proxy is only reachable over the VPN, so when the VPN drops, the browser hangs on a proxy that no longer answers.
PAC Files: Telling the Browser Which Proxy to Use
A proxy auto-configuration file is a text file containing one JavaScript function. The browser downloads it, runs the function for every request, and does what the return value says. Mozilla's documentation defines the signature:
javascriptfunction FindProxyForURL(url, host) {
// ...
}
The function returns a string. DIRECT means go straight to the site. PROXY host:port means use that proxy. SOCKS host:port means use a SOCKS server. Semicolons chain fallbacks, so "PROXY proxy.corp.example:8080; DIRECT" means try the proxy and go direct if it is down.
A handful of helper functions do the matching. isPlainHostName(host) is true for a bare name like fileserver01. dnsDomainIs(host, ".corp.example") matches a domain and its subdomains. isInNet(host, "10.0.0.0", "255.0.0.0") matches an address range. shExpMatch(str, "*.example.com") is a shell-style wildcard. myIpAddress() returns the client's own address, which is how one PAC file behaves differently on the LAN and at home.
A PAC file that keeps internal traffic off the proxy looks like this:
javascriptfunction FindProxyForURL(url, host) {
if (isPlainHostName(host) || dnsDomainIs(host, ".corp.example") ||
isInNet(host, "10.0.0.0", "255.0.0.0")) {
return "DIRECT";
}
return "PROXY proxy.corp.example:8080; DIRECT";
}
Serve it with the MIME type application/x-ns-proxy-autoconfig and a .pac extension.
Two details catch people. shExpMatch(host, "*.example.com") also matches www.example.com.attacker.example, because the wildcard is a glob, not a domain check; use dnsDomainIs for domains. And isPlainHostName only returns true when there is no dot in the name at all, so a short name that your DNS search suffix expands before the PAC function sees it will go to the proxy anyway. This r/sysadmin thread is a clean example of the second one:
Getting the PAC File to the Device
Windows has three ways to find a proxy, and Microsoft's NetworkProxy CSP documentation (March 2025) spells out the order. If auto-detect is on, the device tries to discover a PAC script. If that fails and a setup script URL is set, it downloads that PAC. If that fails and a static proxy is set, it uses the static proxy. Otherwise it goes direct.
Auto-detect is WPAD, Web Proxy Auto-Discovery: the device asks DHCP (option 252) and then DNS (wpad.yourdomain) for the PAC location. Microsoft's own proxy guide (February 2026) recommends it because "it requires no settings on client computers". The catch is that it is discovery by name, and names can be claimed. CISA's alert on WPAD name collisions explains how a laptop that leaves the office can leak a wpad lookup to public DNS, where an attacker who registered the matching domain hands back a hostile PAC file and proxies the user's traffic. CISA's first recommendation: "Consider disabling automatic proxy discovery/configuration in browsers and operating systems unless those systems will only be used on internal networks."
The safer routes are explicit. Set the PAC URL by Group Policy, by Intune using the NetworkProxy CSP (SetupScriptUrl for the PAC, ProxyServer/ProxyAddress for a static proxy, ProxyServer/Exceptions for the bypass list), or by browser policy. Chrome and Edge both take a ProxyMode policy that can be set to pac_script with a ProxyPacUrl, or to fixed_servers, or to direct when you want the browser to ignore the system proxy entirely.
One more trap. Windows has two proxy stacks. WinINET is what the browser and most desktop apps use, and it is what the Settings page configures. WinHTTP is what services use, and it has its own setting, changed with netsh winhttp set proxy. A server that can't reach Windows Update while the browser on it works fine is usually a WinHTTP proxy problem. Microsoft's guide puts it plainly: "Applications that don't obtain proxy settings from Internet Explorer may have to have settings within each app."
The Microsoft 365 Exception
For twenty years the rule was "everything through the proxy". Microsoft now says the opposite for its own cloud.
The Microsoft 365 network connectivity principles (updated August 2026) ask admins to "assess bypassing proxies, traffic inspection devices, and duplicate security technologies" for Microsoft 365 traffic, and list the techniques "known to cause connectivity issues": TLS termination or deep packet inspection of Microsoft 365 domains, and "routing connections through network infrastructure applying its own authentication such as proxy authentication". The reasons are latency and scale. Teams calls hairpinned through a central proxy stack arrive late, and the proxy has to carry every byte of OneDrive sync.
The tool for this is the PAC file. Microsoft's endpoint management guide (June 2026) publishes a PowerShell script, Get-PacFile, that reads the current list of Microsoft 365 endpoints from Microsoft's web service and writes a PAC file that returns DIRECT for the "Optimize" category (Teams media, Exchange, SharePoint front doors) and sends everything else to the proxy. The firewall then needs matching allow rules for those addresses, because the proxy is no longer in the path.
The same principle applies to any SaaS app that breaks behind inspection. Passkeys are the current example: the Entra sign-in flow checks the origin, and a TLS-inspecting proxy in the middle changes it. The fix is a bypass rule, not a bigger proxy.
Setting Up a Proxy for a Small Fleet
Here is the order that avoids the most tickets.
- Decide what the proxy is for. If the answer is "block bad sites", DNS filtering on the endpoint does it with less to maintain. A proxy earns its keep when you need URL-level control, per-user logs, or egress through one address for allow-listing.
- Pick explicit over transparent. Explicit proxies can authenticate users and log by name. Transparent interception can't, and it breaks the TLS assumptions that modern apps rely on.
- Write the PAC file first. Internal names, RFC 1918 ranges and the Microsoft 365 Optimize endpoints go
DIRECT. Everything else goes to the proxy withDIRECTas the fallback so a proxy outage degrades instead of blocking. - Deliver it by policy, not discovery. Group Policy or Intune for the PAC URL. Turn WPAD off on laptops that leave the building.
- Set WinHTTP on servers.
netsh winhttp set proxy proxy-server="proxy.corp.example:8080" bypass-list="*.corp.example;<local>"for anything that runs as a service. - Push the inspection certificate before you turn inspection on. If you inspect TLS at all, the root certificate has to be in every device's trusted store first.
- Keep the bypass list current. Microsoft publishes endpoint changes near the end of each month. Vendors change domains without telling you. A review every quarter is cheaper than the ticket.
- Verify from a device, not from the proxy.
chrome://net-internals/#proxyin Chrome and Edge shows the PAC the browser loaded and the proxy it chose for a URL. On Windows,netsh winhttp show proxyshows the service-side setting.
OpenFrame can run that netsh winhttp show proxy check as a script across a client's devices and collect the output, which is a faster way to find the three servers still pointing at a decommissioned proxy than checking each one by hand.
Where Proxies Fit in 2026
The forward proxy as the single door to the internet is fading. Users work from home, apps live in SaaS, and the traffic that used to backhaul through a head office now goes straight out. The function hasn't gone away; it has moved. DNS filtering took the category blocking, endpoint agents took the per-user logging, and cloud secure web gateways took the inspection for companies that still want it.
What remains is a set of mechanics every technician still has to know. The PAC file, WPAD, the WinHTTP split, CONNECT tunnels and the inspection certificate are the reasons behind a whole category of "works at home, not at the office" tickets. The reverse proxy, meanwhile, is doing more than ever, because every published web app and every CDN is one.
If this post raised a question about what your filtering stack does, the practical next read is attack surface mapping, which covers what a proxy's egress logs can and can't tell you about what is exposed.
FAQ
Is a proxy server the same as a VPN?
No. A proxy forwards requests for specific applications, usually the browser, and decides per URL where they go. A VPN puts the whole device on another network and encrypts every packet. A proxy on its own encrypts nothing; it is the HTTPS between browser and site that does that.
Does a proxy server hide my IP address?
From the destination website, yes: it sees the proxy's address. From the proxy itself and from whoever runs it, no. A corporate proxy logs the original client, and with authentication on it logs the user by name. That is the point of running one.
What is a PAC file and do I need one?
A proxy auto-configuration file is a JavaScript function that tells the browser which proxy to use for each URL. You need one as soon as some traffic should bypass the proxy, which in any Microsoft 365 tenant means immediately. Without it the choice is all traffic through the proxy or none.
What is the difference between a forward proxy and a reverse proxy?
A forward proxy is configured by the client and faces the internet on behalf of users. A reverse proxy is configured by the server owner and faces users on behalf of servers. Same mechanism, opposite direction, different person in charge.
Why does my browser work but Windows Update fails behind the proxy?
Windows has two proxy settings. The browser uses WinINET, set in Settings or by policy. Services like Windows Update use WinHTTP, set separately with netsh winhttp set proxy. A server with a working browser and a failing update is the WinHTTP setting left blank.
Should Microsoft 365 traffic go through the proxy?
Microsoft says no. Its connectivity principles ask admins to bypass proxies, TLS inspection and proxy authentication for Microsoft 365 endpoints, and it publishes a Get-PacFile script that writes the bypass rules for you.
Content Marketing Lead
Ohayo! I run content, SEO, social, and community at Flamingo. Before IT, I worked as a correspondent for Ukraine's Public Broadcasting Company and have a Master's in journalism.
