Skip to main content

Apple Global HTTP Proxy Policy

Updated over a week ago

The Apple Global HTTP Proxy Policy in Swif lets you route all HTTP/HTTPS traffic on a device through a proxy server you control. This is the foundation for:

  • Web content filtering (block/allow specific websites)

  • Secure web gateways / CASB

  • Centralized logging and inspection of web traffic

This is the policy that backs the web filtering design in Jira issue ST‑2618, where Swif uses a global proxy to inspect and filter traffic across browsers and apps, not just Safari.

Policy overview

  • Policy name in Swif: Apple Global HTTP Proxy Policy

  • Purpose: Configure a device-wide HTTP/HTTPS proxy on Apple devices.

  • Minimum OS:

    • macOS 10.9+

    • iOS 6.0+

    • iPadOS 6.0+

  • Supported platforms:

    • macOS

    • iOS

    • iPadOS

  • Ownership types:

    • Company-owned devices

On supervised devices, this can apply device‑wide. On BYOD, you’d typically use this for company‑owned profiles and apps as part of a web filtering or secure browsing strategy.

How the Global HTTP Proxy works

When this policy is applied, the device:

  • Sends all HTTP/HTTPS requests through the proxy defined in the policy.

  • The proxy can:

    • Block/allow URLs and domains (e.g., blacklist phishing sites)

    • Enforce acceptable use policies (e.g., no adult or gambling sites)

    • Log traffic for security and compliance

In ST‑2618, this approach is used as an alternative to Apple’s WebContentFilter payload, which has limitations (e.g., macOS plugin-only behavior and DenyListURLs constraints on iOS). A proxy-based design gives Swif full control over filtering across browsers and apps.

Configuration options in Swif

The policy exposes these main settings:

  1. Proxy Type (proxyType)

  2. Manual proxy settings (for proxyType = Manual)

  3. Auto proxy settings (PAC) (for proxyType = Auto)

  4. Allow Proxy PAC Fallback (proxyPACFallbackAllowed)

  5. Allow Proxy Bypass for Captive Portal Logins (proxyCaptiveLoginAllowed)

Each is described below in plain language.

1. Proxy Type

Field: proxyType
​Display name: Proxy Type
​Required: Yes
​Default: Manual
​Allowed values: Manual, Auto
​Minimum OS: macOS 10.9+, iOS 6.0+, iPadOS 6.0+

What it controls

Chooses how the device learns about the proxy configuration:

  • Manual – You provide:

    • Proxy server address

    • Port

    • Optional username/password

  • Auto – You provide:

    • A PAC (Proxy Auto-Config) URL that returns logic for choosing the proxy based on destination

Dynamic form behavior in Swif

  • If proxyType = Manual, Swif will show:

    • proxyServer

    • proxyServerPort

    • proxyUsername

    • proxyPassword

  • If proxyType = Auto, Swif will show:

    • proxyPACURL

    • proxyPACFallbackAllowed

When to use Manual

  • Simple deployment:

    • Single proxy host/port for all traffic

  • Typical for:

    • A Swif‑hosted or partner‑hosted web filtering proxy

    • Internal corporate proxy with fixed address

When to use Auto (PAC)

  • You need advanced routing logic, for example:

    • Different proxies for different domains

    • Direct access to certain internal sites

    • Complex exception logic

  • You already have an existing PAC infrastructure (e.g., for desktops).

2. Manual proxy settings

Shown only when proxyType = Manual.

a. Proxy Server

Field: proxyServer
​Display name: Proxy Server
​Required: Yes
​Type: String
​Description: “(Required) The proxy server's network address.”

Example values:

  • proxy.company.com

  • 10.0.0.15

This is the hostname or IP of your proxy.

b. Proxy Server Port

Field: proxyServerPort
​Display name: Proxy Server Port
​Required: Yes
​Type: Integer
​Description: “(Required) The proxy server's port number.”

Common values:

  • 3128, 8080, 443, etc.

This must match the port your proxy is listening on.

c. Proxy Username (optional)

Field: proxyUsername
​Display name: Proxy Username
​Required: No
​Type: String
​Description: “The user name used to authenticate to the proxy server.”

Use this if your proxy requires basic authentication or similar. Depending on your design, you might:

  • Use a shared service account for all devices, or

  • Tie credentials to device/user-specific proxy accounts.

d. Proxy Password (optional)

Field: proxyPassword
​Display name: Proxy Password
​Required: No
​Type: String
​Description: “The password used to authenticate to the proxy server.”

Stored encrypted in the MDM payload and used along with proxyUsername to authenticate to the proxy.

3. Auto proxy (PAC) settings

Shown only when proxyType = Auto.

a. Proxy PAC URL

Field: proxyPACURL
​Display name: Proxy PAC URL
​Type: URL
​Description:
“The URL of the PAC file that defines the proxy configuration. Starting in iOS 13 and macOS 10.15, only URLs that begin with http:// or https:// are allowed.”

Examples:

Notes:

  • The PAC file contains JavaScript that determines the correct proxy or direct connection for each request.

  • For modern OS versions, file:// and other schemes are not allowed; you must host the PAC file over HTTP/HTTPS.

b. Allow Proxy PAC Fallback

Field: proxyPACFallbackAllowed
​Display name: Allow Proxy Pac Fallback
​Type: Boolean
​Default: false
​Minimum OS: macOS 10.9+, iOS 7.0+, iPadOS 6.0+
​Description:
“If true, allows connecting directly to the destination if the proxy autoconfiguration (PAC) file is unreachable.”

Behavior:

  • If true:

    • When the PAC file cannot be reached, the device may fall back to a direct connection (no proxy).

    • This improves availability (users keep internet access) but weakens enforcement, because traffic may bypass your proxy and web filter when the PAC is down.

  • If false:

    • If the PAC file is unreachable, traffic does not silently fall back to direct access.

    • This enforces stronger security: no PAC = no browsing, which is often the desired outcome for strict environments.

Recommended for strict filtering:

  • Set proxyPACFallbackAllowed = false to prevent silent bypass if the PAC server is down.

4. Allow Proxy Bypass for Captive Portal Logins

Field: proxyCaptiveLoginAllowed
​Display name: Allow Proxy Bypass for Captive Portal Logins
​Type: Boolean
​Default: false
​Minimum OS: macOS 10.9+, iOS 7.0+, iPadOS 6.0+
​Description:
“If true, allows the device to bypass the proxy server to display the login page for captive networks.”

Captive portals are the login/acceptance pages you see on:

  • Hotel Wi‑Fi

  • Airport Wi‑Fi

  • Guest networks

Behavior:

  • If true:

    • The device can temporarily bypass the proxy to load the captive portal login page.

    • This improves usability on public/guest networks where the portal might not be reachable through the proxy.

  • If false:

    • All traffic, including captive portal attempts, must go through the proxy.

    • On some networks, this may prevent users from completing the login, effectively blocking internet access until the network is manually adjusted.

Recommended approach:

  • If your devices often move between networks (e.g., laptops, mobile devices on public Wi‑Fi), set this to true to avoid user confusion and connectivity issues.

  • In very locked‑down environments (e.g., kiosks on controlled networks), you may keep this as false and ensure networks are configured without captive portals.

Example use cases

1. Web content filtering for phishing/adult/gambling sites (ST‑2618)

For customers like Prematex, Alchemic, UnitX, or Splashtop who want blacklisting/whitelisting:

  • Deploy a Global HTTP Proxy that points to:

    • A Swif‑managed local or remote proxy;

    • Or a third‑party secure web gateway.

  • Use your proxy’s rules to:

    • Block phishing domains

    • Block categories (adult, gambling, etc.)

    • Allow only approved domains in “whitelist” mode

Typical settings:

  • proxyType: Manual

  • proxyServer: e.g., proxy.swifteam.com

  • proxyServerPort: e.g., 3128

  • proxyUsername / proxyPassword: set if required

  • proxyCaptiveLoginAllowed: true (for mobile users)

  • If using PAC instead, proxyType = Auto and configure proxyPACURL + proxyPACFallbackAllowed = false for strict enforcement.

2. Secure web gateway for remote workers

For remote Mac/iOS users where you want all web traffic to go through a corporate security stack:

  • Use proxyType = Manual or Auto (PAC) pointing to your SWG / CASB.

  • Keep proxyPACFallbackAllowed = false to ensure workers cannot bypass the SWG by breaking the PAC.

  • Consider proxyCaptiveLoginAllowed = true to avoid blocking captive portal logins on hotel/guest Wi‑Fi.

Behavior and trade-offs

  • Local proxy on device:

    • Pros: Works offline / local logic, low latency

    • Cons: If local proxy binary dies or is blocked, users might be stuck unless Swif removes the profile.

  • Server (cloud) proxy:

    • Pros: Centralized logic, easier to scale and manage rules, more secure for enforcement

    • Cons: Some latency added (all traffic goes through remote data center)

Regardless of whether you choose a local or server proxy implementation, the Apple Global HTTP Proxy Policy is the mechanism Swif uses to force traffic through that proxy.

Related Articles
Enrolling Apple Devices to Apple Business Manager (ABM) with Apple Configurator
Troubleshooting DEP Enrollment Error: “An error occurred while obtaining automatic configuration settings”
Apple-specific MDM policies available in Swif
Apple VPN Policy
Apple Wi-Fi Policy
Did this answer your question?