Jira Cloud network problems: common causes and a Admin Playbook

Arkadiusz Wroblewski

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”

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