Privoxy

Sign in to the Azure Portal, choose Create a resource, and search the Marketplace for Privoxy by SecureAnyCloud. Select the listing and choose Create.

On the Basics tab, pick your subscription, resource group, region and VM size (Standard_B2s or larger). Under Administrator account, select SSH public key, set the user name, and paste your public key.

Under Inbound port rules, allow SSH (22) for administration. You add the proxy rule (TCP 8118), scoped to your client subnets, after you open the proxy. Select Review + create, then Create. First-boot initialization completes within a few seconds of the VM reaching the Running state.

The following commands create a VM from the SecureAnyCloud Privoxy image in an existing VNet and subnet. Replace the values in angle brackets with your own.

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:privoxy-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name privoxy \
  --image sac1647283583153:privoxy-ubuntu-24-04:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard
# Once you widen the proxy, allow 8118 from your client subnet only — never from the internet.
az vm open-port --resource-group <your-rg> --name privoxy --port 8118 --priority 1010

Connect to the VM over SSH as the administrator user you set at deploy time (azureuser by default on Ubuntu). The administrator account accepts SSH keys only.

ssh azureuser@<vm-public-ip>

Privoxy starts automatically on boot. Confirm that the service is active and bound to the loopback address only, and inspect the shipped hardened configuration:

systemctl is-active privoxy.service
sudo ss -tlnp | grep ':8118' grep -E '^\s*(listen-address|permit-access|enable-edit-actions|enable-remote-toggle)\s' /etc/privoxy/config

The listener line shows 127.0.0.1:8118, so the proxy is bound to loopback only, which is the secure default. The configuration shows the permit-access client list restricted to loopback and the RFC1918 ranges. It also shows enable-edit-actions 0, so the rules cannot be edited remotely.

Prove that the proxy works directly on the server. First, request Privoxy's own built-in admin page through the proxy. Privoxy generates this page itself, so it needs no outbound connection. Then fetch a real web page through the proxy:

curl -sx 127.0.0.1:8118 http://p.p/ | grep -i '<title>'
curl -sx 127.0.0.1:8118 -o /dev/null -w 'show-status: HTTP %{http_code}\n' http://p.p/show-status
curl -x 127.0.0.1:8118 http://www.example.com/ | grep -i '<title>'

The admin page title (Privoxy@localhost) confirms that the proxy accepts and intercepts requests. The Example Domain title confirms that a real page was fetched cleanly, end to end, through the proxy.

Privoxy's default action and filter rules are active out of the box. The show-url-info page reports the actions that apply to any URL, without ever fetching the URL. Use it to inspect a known ad server, then confirm that the server is blocked:

curl -sx 127.0.0.1:8118 'http://p.p/show-url-info?url=http://ads.doubleclick.net/adj/track.js' | sed 's/<[^>]*>//g' | grep -oE '[{][^{}]*block[^{}]*[}]' | sort -u
curl -sx 127.0.0.1:8118 -o /dev/null -w 'ads.doubleclick.net through the proxy: HTTP %{http_code}\n' http://ads.doubleclick.net/adj/track.js

The matched {block} actions show that the ad-blocking rules catch the request. The blocked request returns HTTP 403, because Privoxy serves its own block page and never connects out to the ad server.

Add your own rules in /etc/privoxy/user.action (block lists) and /etc/privoxy/user.filter (content filters), then reload with sudo systemctl reload privoxy.

Read the first-boot information file and the proxy summary at any time. The file records the server's private IP and the exact commands to open the proxy to your clients:

sudo cat /root/privoxy-info.txt
sudo privoxy-access status

The image ships with Privoxy bound to 127.0.0.1 only and the client list restricted to loopback plus RFC1918. This is deliberate: no client on the network can use the proxy until you widen the bind.

When you are ready, use the privoxy-access tool to bind to the VM's private IP and permit your client subnet. Use your own client subnet's CIDR. The value below is only an example:

sudo privoxy-access listen private
# bind to this VM's private IP on :8118 sudo privoxy-access allow 10.1.0.0/24 # permit your client subnet (RFC1918)
sudo privoxy-access status

An open proxy is refused as a hard guardrail. The tool rejects both privoxy-access allow 0.0.0.0/0 and privoxy-access listen 0.0.0.0:8118, so you cannot accidentally expose the proxy as an abuse relay to the whole internet. After you widen the bind, scope the NSG rule for TCP 8118 to your client subnets only.

After you widen the bind and permit the client subnet, point a client's HTTP and HTTPS proxy at the server's private IP address on port 8118 (shown in /root/privoxy-info.txt). To test quickly, run these commands from a Linux client in the allowed network:

# On the client, using the server's private IP:
curl -x http://<server-private-ip>:8118 http://www.example.com/
# Or set it for the whole shell session:
export http_proxy=http://<server-private-ip>:8118
export https_proxy=http://<server-private-ip>:8118
curl http://www.example.com/

To configure a browser, set its HTTP and HTTPS proxy to <server-private-ip>:8118. To apply the proxy system-wide on Ubuntu or Debian clients, set http_proxy / https_proxy in /etc/environment, or drop an apt proxy file into /etc/apt/apt.conf.d/.

The privoxy-access tool is the primary interface to the bind and the client access list. It supports these commands:

• privoxy-access status: Show the listen address, the client access list and the service state
• privoxy-access listen loopback: Bind to 127.0.0.1:8118 (the closed default)
• privoxy-access listen private: Bind to this VM's private IP on :8118
• privoxy-access allow <CIDR\|host>: Permit a client network (added to permit-access)
• privoxy-access deny <CIDR\|host>: Block a client network (added to deny-access)

You can also edit /etc/privoxy/config directly and run sudo systemctl reload privoxy to apply changes. The privoxy-access guardrails apply only to the tool. Revoke a client network when it no longer needs the proxy:

sudo privoxy-access deny 10.1.0.0/24

The image is hardened out of the box. Privoxy binds to loopback only, its client access list admits loopback and RFC1918 only, the built-in config pages are read-only, and the privoxy-access tool refuses an open-proxy configuration.

Keep it locked down in production:

• Bind to the private IP rather than all interfaces.
• Keep the client access list scoped to the narrowest CIDR ranges you trust.
• Scope the NSG rule for TCP 8118 to only the client subnets that need the proxy, and never expose 8118 to the internet.
• Keep the OS patched (sudo apt update && sudo apt upgrade).

Review your user.action and user.filter rules periodically. Consult the Privoxy user manual for the full action and filter reference.