Safari No Longer Sends User-Agent header in CONNECT — Impact on EdgeSWG (ProxySG) Filtering Rules.

Products

• ISG Proxy
• ProxySG Software - SGOS

Issue/Introduction

During testing for blocking file extensions, domains does not get block with Safari but works correctly against Chrome/Mozilla.

Environment

Safari on Apple iOS 15.0 and later

Transactions: Explicit proxied HTTPS transactions

Layers impacted on ProxySG : <Proxy> , <SSL-Intercept>

Cause

This behavior starts with Safari on Apple iOS 15.0 and later. Beginning with this version, Safari no longer includes the User-Agent header in HTTP CONNECT request, which affects how ProxySG (EdgeSWG) apply browser-specific policies.

Resolution

Safari Browser no longer includes the User-Agent header in HTTP CONNECT requests. This means:

• Policies using http.connect.User-Agent will not match Safari traffic.
  
  
• This impacts SSL interception, authentication, and filtering rules that depend on identifying the browser at the CONNECT stage.
  
  
• Packet captures confirm that Safari’s CONNECT requests now contain an empty or missing User-Agent header, causing rule mismatches.
  
  
• In Policy Trace, such rules will appear as "n/a".

        <ssl-intercept>
        n/a: http.connect.User-Agent.exact="Safari_browser" ssl.forward_proxy(yes)

• If you've created rules to control traffic based on browser type—such as allowing Chrome and blocking Safari—those rules may not be enforced by the proxy because Safari's CONNECT requests do not include a User-Agent header.

Recommended Actions:

• Avoid relying on http.connect.User-Agent for Safari-specific rules.
• Consider alternative identifiers such as Client IP, authenticated user or groups for rule based match.