Jira Cloud network problems: common causes and a Admin Playbook

[#1]

How Jira Cloud traffic typically flows

A normal page load is not “one request”. It’s a chain:

1. DNS resolves multiple Atlassian domains

2. Browser opens TCP 443 and negotiates TLS

3. Content is served via CDN (static JS/CSS)

4. Browser talks to REST APIs (JSON) for issues/boards

5. Some features rely on long-poll / WebSocket-like behavior (and modern HTTP features like HTTP/2)

If any layer is modified or blocked (proxy auth, SSL interception, DNS rewrite, cookie stripping), Jira looks “broken” in ways that are hard to diagnose unless you check systematically.

The “symptom → likely cause” map

A) Blank page / UI loads partially / endless spinner

Most likely

• Static assets blocked (JS/CSS not loading)

• Proxy blocks or rewrites content

• SSL inspection breaks modern TLS

What you’ll see

• Browser dev tools: failed requests for JS/CSS, blocked scripts, 403/407, or certificate errors

• Page HTML loads but the app never “boots”

B) Login loop / keeps sending you back to login

Most likely

• Cookies blocked/rewritten (privacy tooling, proxy, endpoint security)

• SSO/IdP path blocked by firewall/proxy

• TLS inspection interfering with auth redirects

What you’ll see

• Repeated redirects between auth endpoints

• Cookies not being set, or SameSite warnings in console

C) Works on hotspot, fails on corporate network

Yep  that’s almost always:

• Firewall/proxy block

• SSL inspection

• DNS/VPN split-tunnel problem

D) Attachments / images fail (issues load, but files don’t)

Most likely

• Media/attachment endpoints blocked by firewall/proxy category rules

• SSL inspection breaks large downloads or streaming

• DLP tools blocking file transfer patterns

What you’ll see

• 403/timeout on download endpoints while API calls still succeed

E) Marketplace/app install fails, “we ran into a little trouble”

Most likely

• Proxy blocks Marketplace domains

• Admin permissions are fine but network denies the install flow

• TLS inspection causing intermittent install calls to fail

F) Only some offices/countries/ISPs can’t access

Most likely

• ISP routing issue

• Bad DNS in one region

• One egress IP not included in org allowlist

The high-value checks

1) Confirm it’s not an Atlassian incident

Do this first so you don’t burn hours on your own network.

2) Check org-level IP allowlisting (self-inflicted outages)

If your org uses IP allowlisting for product access, Jira Cloud will be “unavailable” for users whose egress IP isn’t allowlisted.

Key points

• “User IP” is not the laptop’s IP. It’s usually the NAT/proxy/VPN egress IP.

• VPN changes egress. So does SASE (Zscaler/Netskope/etc.).

Fix

• Maintain a single, owned list of all egress IPs (office + VPN + proxies) and keep it current.

• Treat changes to allowlisting as a controlled change with rollback.

Warning

• One wrong allowlist change can block a whole site. Keep admin recovery access documented.

3) Firewall/proxy allowlisting (domains + IP ranges)

Jira Cloud does not live on one IP. Atlassian publishes IP ranges and required domains for Cloud products.

What to do

• Allow outbound HTTPS (443) to Atlassian Cloud domains and IP ranges.

• If you do “FQDN allowlisting”, include all Atlassian domains needed for:

  • the site (*.atlassian.net)

  • authentication (id.atlassian.com style endpoints)

  • APIs (api.atlassian.com patterns)

  • media/attachments endpoints

  • Marketplace (for app installs)

Warning

• “We allow *.atlassian.net so we’re done” is often false. Auth, API, and media can use additional domains.

4) SSL/TLS inspection (MITM) exclusions

This is the #1 cause of “random” Jira Cloud failures.

Why it breaks

• Modern web apps use strict TLS, HTTP/2, and security headers.

• SSL interception devices sometimes:

  • present a substituted certificate that some clients don’t trust

  • downgrade HTTP/2

  • break content encoding

  • interfere with websockets/long-lived connections

Fix

• Exclude Atlassian Cloud domains from SSL inspection (best).

• If your policy forces inspection, ensure:

  • inspection CA is trusted everywhere (including VDI, managed browsers)

  • HTTP/2 and websockets/streaming are supported end-to-end

  • no header/cookie rewriting is happening

5) DNS / VPN split-tunnel sanity

Common failure

• Corporate DNS returns different answers than public resolvers

• Split tunnel sends Atlassian traffic into a path that blocks it

What “good” looks like

• Consistent DNS resolution across offices/VPN

• No DNS rewrite to internal proxy endpoints that can’t reach Atlassian

What to collect (so the network team can’t hand-wave it away)

Browser-side evidence (most useful)

• A full-page load HAR capture (Network tab, preserve log, disable cache, reload)

• Console errors (copy/paste)

• The exact failing request(s): URL, status code, timing

Patterns that matter

• 407 Proxy Authentication Required → proxy auth issue

• 403 on static assets → filtering/allowlisting

• net::ERR_CERT_* → TLS inspection/cert chain

• CORS/blocked by policy → proxy/extension/security tooling

Network-side evidence

Run these from an affected machine (or from inside the corporate network segment):

• nslookup <your-site>.atlassian.net

• tracert <your-site>.atlassian.net (Windows) / traceroute (macOS/Linux)

• curl -v https://<your-site>.atlassian.net (shows TLS and proxy behavior)

• openssl s_client -connect <your-site>.atlassian.net:443 (certificate chain, SNI behavior)

What you’re looking for

• DNS resolves consistently

• TLS handshake completes without interception surprises

• No forced proxy that blocks required hosts

Concrete remediation patterns

“Works on hotspot” remediation

• Disable SSL inspection for Atlassian domains

• Allowlist Atlassian IP ranges + required domains on egress firewall/proxy

• Verify proxy supports HTTP/2 and long-lived connections

“Only one office fails”

• Compare egress IP and DNS resolver against a working office

• Check local proxy policy differences (categories, SSL inspection, DLP)

“Only attachments fail”

• Confirm media/attachment domains are allowed

• Check DLP/file transfer rules and max object size/timeouts on proxy

“Login loop”

• Stop cookie/header rewriting on the auth path

• Exclude auth endpoints from interception

• Ensure browser privacy tooling isn’t blocking required cookies

Operational advice (keeps it fixed)

• Treat Atlassian Cloud allowlisting as living configuration, not a one-time change.

• If you rely on IP ranges, update them automatically (don’t wait for outages).

• Keep a small “known good” path documented (e.g., hotspot test + clean browser profile) for quick isolation.

• Document who owns what: Org allowlist vs firewall/proxy vs endpoint security.

Short warning that saves incidents

If your org has both:

• Atlassian IP allowlisting, and

• VPN/SASE egress changes

…then Jira Cloud “unavailable” incidents are inevitable unless egress ownership is clean and updated with change control.

Helpful Articles:

Jira status: https://jira-software.status.atlassian.com/

Atlassian global status hub: https://status.atlassian.com/

IPs/domains for Atlassian Cloud: https://support.atlassian.com/organization-administration/docs/ip-addresses-and-domains-for-atlassian-cloud-products/

IP ranges feed: https://ip-ranges.atlassian.com/

Atlassian Admin IP allowlisting: https://support.atlassian.com/security-and-access-policies/docs/specify-ip-addresses-for-product-access/

“Certain sites/locations can’t access instance” KB: https://support.atlassian.com/atlassian-cloud/kb/unable-to-access-atlassian-cloud-instance-from-certain-sites/

HAR capture guide: https://confluence.atlassian.com/kb/generate-har-files-and-analyze-web-requests-for-atlassian-support-720420612.html

[John Johnson]

Great breakdown of the common Jira Cloud networking issues. For admins who want to learn more, it’s really helpful to understand how modern web apps depend on multiple layers like DNS resolution, TLS negotiation, CDNs, and REST APIs. Many times when Jira appears “broken,” the real issue isn’t Jira itself but something in the network path modifying or blocking requests.

I also agree that SSL inspection and proxy configuration are some of the most frequent culprits. In many enterprise environments, security appliances intercept TLS traffic, which can unintentionally break HTTP/2, content encoding, or long-lived connections used by modern applications. When that happens, you get strange symptoms like partial UI loads, login loops, or failed attachments.

Another point that stands out is the importance of documenting egress IPs and maintaining proper . Many organizations overlook how VPNs, SASE platforms, or regional gateways can change the effective IP address seen by cloud services. Without a controlled process for updating , it’s easy to accidentally block legitimate users.

Overall, the “symptom → likely cause” mapping is especially useful for troubleshooting because it helps admins quickly narrow down where to start investigating instead of randomly testing different network components. This kind of systematic approach saves a lot of time when diagnosing cloud application connectivity problems.