Optimizing Atlassian Cloud Performance with TLS and Firewall Best Practices

[Mohamed Almoaz]

Enterprise security is evolving. Today’s organizations rely on a range of controls—TLS/HTTPS inspection proxies, firewalls, Secure Web Gateways (SWG), and Cloud Access Security Brokers (CASB)—to protect data, enforce compliance, and meet regulatory demands. These tools are essential for visibility and control, especially as Data Loss Prevention (DLP) and regulatory requirements intensify.

However, these same controls can unintentionally degrade the performance of Atlassian Cloud products. The most common culprit? Downgrading modern HTTP/2 traffic to legacy HTTP/1.1, which results in slower page loads, laggy interactivity, and a noticeably less responsive experience for users.

Atlassian Cloud products depend heavily on HTTP/2 features—parallel streams, multiplexing, and efficient resource loading. When traffic is downgraded, requests are forced to run sequentially, causing longer load times and degraded responsiveness across Jira, Confluence, and other Atlassian Cloud experiences.

Key impact

• Jira Cloud: +1.5–2 seconds additional Time to Interactive (TTI)

• Confluence Cloud: +4–9 seconds additional TTI

• All Atlassian Cloud products: are affected, including JSM, Compass, Rovo, Bitbucket, and Trello.

Across thousands of users and daily workflows, these delays compound into a significant productivity cost.

Common enterprise security product

Many enterprise customers use tools such as proxies, firewalls, Secure Web Gateways (SWG), and Cloud Access Security Brokers (CASB) to secure their networks. Below are some of the most common products we see in customer environments that can influence performance if not configured correctly.

Common examples include:

• Palo Alto Networks (SSL Inbound Inspection)

• Zscaler (ZIA/ZPA with optional HTTP/2 support)

• Symantec / Broadcom ProxySG

• Sophos XG Firewall

• Microsoft Defender for Cloud Apps (MCAS)

These are among the most common tools seen in enterprise networks, but there are many others — including McAfee, Netskope, Skyhigh, and Cyberoam — that operate similarly.

By default, many of these tools force HTTP/1.1 unless explicitly configured to support HTTP/2.

How TLS inspection/firewalls impact Atlassian Cloud

When traffic passes through TLS inspection or firewall systems, it doesn’t reach Atlassian Cloud directly. Instead, it’s decrypted and re-encrypted by these security controls for inspection. While this is normal in enterprise environments, the process can unintentionally change how browsers communicate with Atlassian Cloud.

Specifically, it can break support for HTTP/2, the protocol Atlassian Cloud depends on for fast and parallel data loading. When that happens, browsers fall back to HTTP/1.1, and several performance issues appear:

• Man-in-the-middle behaviour: TLS streams are intercepted, decrypted, and re-encrypted by the proxy.

• Protocol downgrade: Many inspection products do not support HTTP/2, forcing clients to fall back to HTTP/1.1.

• Serialization of requests: Browsers restrict simultaneous HTTP/1.1 connections, so hundreds of small asset/API requests queue up.

• User impact: Pages feel slower, actions hang, and overall productivity drops.

Note: We’ve heard from many enterprise customers experiencing these exact slowdowns. Our performance and support teams have analyzed their environments and confirmed that TLS inspection and protocol downgrades are key contributors.

Recommended best practice

To address the performance degradation caused by TLS inspection, Atlassian recommends the following configuration approaches. These best practices have been validated across multiple enterprise environments.

Option 1 (short/mid-term): Exclude Atlassian domains from TLS inspection

The most effective and immediate solution is to allow-list Atlassian’s domains so they bypass TLS interception.

Core domains:

• *.atl-paas.net

• *.atlassian.com

• *.atlassian.net

• *.jira.com

• *.bitbucket.org

• *.trello.com

Tips:

• Use multi-level wildcards (e.g. *.prod.public.atl-paas.net) to capture subdomains.
• Include Cloudfront CDN domains (*.cloudfront.net) used by Atlassian teams for static asset delivery.
• Ensure top-level domains are included (e.g. atlassian.com as well as *.atlassian.com).

Option 2 (mid/long-term): Configure your inspection tools to support HTTP/2

If exclusion is not possible due to corporate policy, work with your networking/security teams (and your proxy vendor) to enable HTTP/2 inspection.

• Palo Alto: HTTP/2 inspection is enabled by default when SSL Inbound Inspection is configured.

• Zscaler: HTTP/2 inspection is disabled by default, but Zscaler has published detailed guidance on how to enable it:

  • Zscaler & Atlassian Best Practices for HTTP/2 – Part 1

  • Zscaler & Atlassian Best Practices for HTTP/2 – Part 2

• Other vendors: Many inspection products do not support HTTP/2 at all, or require explicit configuration changes to allow it.

Important: HTTP/2 cannot be “forced” by Atlassian or the browser. It must be allowed by the TLS inspection proxy/firewall.

How to confirm your setup

Once you’ve applied these configurations, you can verify their effect by testing whether Atlassian Cloud traffic is using HTTP/2:

1. Collect a HAR file from the browser.

2. Check protocol versions — requests to Atlassian domains (*.atl-paas.net, *.atlassian.net, *.atlassian.com) should use HTTP/2 consistently.

3. If you see multiple requests falling back to HTTP/1.1, performance degradation is likely caused by TLS inspection that’s still active.

What you need to know before allow-listing Atlassian domains

After implementing the recommended allow-listing configuration, many enterprise admins and network teams have understandable questions about ownership, security, and operational safety.
This section addresses the most common questions we receive to help you make these configuration changes with confidence.

1. Who controls these domains?

All domains under *.atl-paas.net are fully owned and controlled by Atlassian. They are not shared with third parties. These domains serve assets built by Atlassian’s own pipelines from Atlassian’s own source code.

2. Why is a wildcard needed instead of individual domains?

• Atlassian products dynamically generate many subdomains under *.atl-paas.net for static asset delivery.

• A single page load can trigger dozens or hundreds of requests to these domains.

• Because these subdomains change over time (e.g. when new product teams spin up new services), a static list of FQDNs quickly becomes outdated.

• Wildcard allow-listing ensures resilience: customers avoid sudden performance regressions when new subdomains are introduced.

• Domains under this zone may also include multiple subdomain levels (e.g., jira-frontend-static.prod.public.atl-paas.net). Your allow-list/bypass must handle this.

3. Are assets delivered from these domains secure?

Yes. Atlassian maintains strict security across its entire software supply chain:

• SAST: Semgrep

• SCA: Endor, Snyk

• DAST: Burp Suite

• Vulnerability scanning: Tenable

All assets are continuously scanned as part of Atlassian’s CI/CD pipelines.

4. Do these domains handle interactive traffic (POST/PUT), or only static GET requests?

Domains under *.atl-paas.net only deliver static public assets (JavaScript, CSS, images, fonts, etc.) that are required to render Atlassian Cloud applications in the browser.

• They do not accept interactive requests (POST/PUT).

• They are strictly used for serving Atlassian-generated static content.

5. What is the performance impact of not allow-listing?

TLS inspection of *.atl-paas.net assets can add 2–4 seconds to every page load.

• The impact varies by proxy/firewall vendor, geography, and configuration.

• In global enterprise rollouts, this can translate into significant productivity loss.

Final recommendations

• Exclude Atlassian domains, especially *.atl-paas.net, from TLS inspection.

• Use multi-level wildcards to handle evolving subdomains.

• Trust the supply chain: Atlassian continuously scans and secures all assets delivered through this zone.

• Validate via HAR analysis to confirm if your network setup is downgrading HTTP/2.

By following these practices, enterprise customers can ensure their teams get the best possible Atlassian Cloud performance while maintaining strong security and compliance.

---

For reference, please review Atlassian’s official documentation on IP addresses and domains for Atlassian Cloud products.

[Thiago P _Atlassian Support_]

Amazing article, thank you @Mohamed Almoaz ! =]