IP addresses and domains for Atlassian cloud apps

If you or your organization use restrictive firewall or proxy server settings, you or your network administrator may need to allowlist certain domains and IP address ranges to ensure Atlassian cloud apps and other services work as expected. 

ドメイン名

Atlassian apps use domains with many levels of subdomains under all the listed top-level domains. When allowing a domain, make sure the action permits the top-level domain and multiple levels of subdomains, not just immediate subdomains.

たとえば、*.atl-paas.net の許可エントリに関しては、avatar-management--avatars.us-west-2.prod.public.atl-paas.net と jira-frontend-static.prod.public.atl-paas.net の両方を許可する必要があります。さらに、サブドメインだけでなく上位ドメイン自体が許可されていることをご確認ください。たとえば、*.atlassian.com は id.atlassian.com と atlassian.com の両方を許可する必要があります。

アトラシアン ドメイン

For Atlassian apps to operate, allow these first-party Atlassian domains and their levels of subdomains. These domains are directly operated and managed by Atlassian.

Atlassian Government Cloud ドメイン

For Atlassian Government Cloud apps to operate, allow these first-party Atlassian domains and their levels of subdomains. These domains are directly operated and managed by Atlassian.

パートナー ドメイン

Atlassian uses third-party domains and their levels of subdomains for various purposes. Atlassian apps and services may work without access to these domains, however some experiences may be degraded or stop functioning altogether.

IP アドレスの範囲

We use a mix of our own IP addresses and others provided by third parties (namely Amazon Web Services). You should review your network restrictions in the context of the following sections and update them as necessary to ensure your Atlassian apps work as intended.

These addresses were last updated on April 3, 2025.

Atlassian apps and sites

Atlassian apps and sites don't have fixed individual IP addresses. Instead, they use defined ranges of IP addresses. You should allowlist these IP ranges to maintain access to Atlassian cloud apps and sites.

This list is sizable because it contains every IP range used globally by Atlassian. The IP ranges are used for both receiving and responding to requests from clients (e.g., browsers), as well as for making connections to the internet on your behalf (e.g., webhooks and application links to on-premise servers).

In practice, most admins operating allowlisting systems (such as firewalls, access control lists, and security groups) are only interested in the IP ranges Atlassian apps use to make outgoing connections to other networks. For this much shorter list, see the Outgoing connections section.

Outgoing connections

The IP address ranges for Atlassian apps and sites include both the summary IP ranges used for ingress and egress, as well the more specific ranges used only for egress. We generally recommend using these IP address ranges when you allow our outgoing connections to contact remote networks and servers.

Atlassian apps may connect using either IPv4 or IPv6. This depends on the resolution time for the A and AAAA DNS record by our proxies. Atlassian apps and services will originate connections to the internet, remote servers, and third parties only.

IP 許可リスト、サーバー、ファイアウォール、アクセス制御リスト、セキュリティ グループ、またはサードパーティのサービスを、アトラシアンからの発信接続を受信するように設定している場合は、次のリストをご利用ください。

Outgoing connections for Atlassian apps

If your situation requires a simple list of the IP ranges used by Atlassian only for the purpose of making outgoing connections, you can use the following lists.

IPv4

IPv6

For IPv6, you can choose to use summary ranges or the individual Atlassian IPv6 ranges used for outgoing connections. The summary option can help if you have limited space available in your access-list or security-group and is less likely to change over time. The individual ranges option are useful if your policy or software prevents the use of a summary range.

Atlassian Government Cloud の発信接続

Jira for Atlassian Government Cloud supports development integrations with Github, not other development tools. If your situation requires a list of IP ranges used by Atlassian only for the purpose of making outgoing connections, you can use this list:

Amazon Web Services and CloudFront

We use CloudFront Content Delivery Network (CDN) to deliver webpage assets to browsers as well as various Amazon Web Services. Customers employing strict network restrictions on destinations allowed for client browsers may find it necessary to allowlist IP ranges with the tags "AMAZON" or "CLOUDFRONT" from this IP ranges list to ensure Atlassian apps work properly.

送信メール

We use these IPs to send notifications. You should allow the following IP ranges:

Bitbucket と Trello

Some Atlassian apps aren’t hosted on the same atlassian.net domain as Confluence and Jira. Check these articles to find out which domains, IP address ranges, and ports you need to allow for certain apps:

• Bitbucket: IP addresses and domains to allowlist in your corporate firewall

• Trello: Configure your firewall for Trello

Bitbucket Cloud Premium customers

If you’re a Bitbucket Cloud Premium customer and have set a custom IP allowlist, make sure you also include the IP of your Bitbucket Data Center. Control access to your private content

Confluence ホワイトボード

If you’re not able to allowlist *.atlassian.com, you can make http://canvas-workers.atlassian.com an allowed domain to avoid issues with Confluence whiteboards. To check your compatibility with the whiteboards editor, use our compatibility check tool.

Integrate with Data Center products

ネットワークで稼働しているアトラシアンのクラウド製品とオンプレミス製品の統合を検討されている場合は、アプリケーション トンネルを使用することで、着信接続と IP 範囲を許可リストに登録せずに済みます。 

Application tunnels use network tunneling to create a secure pathway between Atlassian cloud and the products in your network that can be used to integrate your products. We made this feature so you don’t have to open your network for any incoming connections. Connect to Data Center instances with application tunnels

アトラシアンの公開 IP 範囲に関する FAQ

Jira/Confluence Cloud を自社ホスト製品やサービスと統合しています。インフラストラクチャとの接続を開くためにアトラシアンが使用する IP 範囲はどれくらいですか?

Atlassian has a number of egress proxies which use IP ranges specifically dedicated to opening connections from Atlassian cloud to customers and remote systems. The proxies are deployed in each AWS region where our Jira/Confluence infrastructure is deployed. These IP ranges can be found in the Outgoing connections section on this page.

Instead of allowlisting these IP ranges, you can also use application tunnels to integrate with Atlassian cloud apps in your network. Application tunnels use network tunneling to forward the traffic to your network without requiring any incoming connections. See the Integrate with Data Center products section on this page.

上記の IP 範囲は誰が管理しますか?

Atlassian has full control over those IP ranges. These IP ranges are allocated out of the AWS-registered IP space. Those ranges have been dedicated by AWS to one of Atlassian’s AWS accounts. No other AWS customer can use these IP ranges.

The allocation/deallocation of such ranges is done using a manual process which involves a support request. It is very unlikely that Atlassian will release control over these ranges accidentally. We have monitoring in place to detect such unlikely occurrence as well.

Jira/Confluence Cloud インスタンスがどのリージョンにあるか確認するにはどうすればよいですか?

Your app data will most likely have a large hosting presence within the region closest to the majority the users accessing your apps. To optimize product performance, we don’t limit data movement in cloud and we may move data between regions as needed.

If you’re opted in to data residency, which is currently available with the Enterprise Cloud plan and new apps with no data for with Standard and Premium Cloud plans, you will be able to restrict the number of regions where connections from Atlassian cloud to your infrastructure can be expected to the regions where your data is pinned to. Understand data residency

IP 範囲が変わることはありますか?

変更が最小限に収まるように善処しますが、IP 範囲が変更になる可能性があります。次の場合、IP 範囲に関する情報の追加または変更が必要になる可能性があります。

• If we add AWS regions where we host Jira/Confluence Cloud, we’ll add a new subnet for the new region.

• If we deploy new instances of our egress proxies that use Atlassian-registered (provider-independent) IP space within AWS and Jira and Confluence switch over to those, we’ll use new ranges that will be part of the Atlassian-registered netblocks (104.192.136.0/21 and 185.166.140.0/22). We’ll publish a blog post a few weeks before that change is made. All ranges, old and new, are covered by these IP ranges.

IP 範囲が変更されたときはどうすればわかりますか?

アトラシアンの IP 範囲が変更されるたびに、SNS トピック atlassian-public-ip-changes の登録者に通知を送信します。ペイロードには次の形式の情報が含まれており、マシンによる利用を目的としています。

• creationDate - IP 範囲が UTC でアップデートされた日時 (標準 ISO 形式)。

• syncToken - Unix エポック時間形式の公開時間。

• md5 - IP 範囲ファイルの暗号化されたハッシュ値。この値を使用して、ダウンロードされたファイルが破損しているかどうか確認できます。

• url - IP 範囲ファイルの場所。

If you want to be notified whenever there's a change to the Atlassian IP ranges, subscribe to receive notifications using Amazon SNS.

Subscribe to notifications for Atlassian IP ranges

1. Amazon SNS コンソール (https://console.aws.amazon.com/sns/v3/home) を開きます。

2. ナビゲーション バーで、必要に応じて [地域] を [米国東部 (北バージニア)] に変更します。配信登録している SNS 通知が作成された地域であるため、この地域を選択する必要があります。

3. In the navigation pane, select Subscriptions.

4. [Create subscription (登録の作成)] を選択します。

5. [Create subscription (登録の作成)] ダイアログ ボックスで、以下を行います。

   1. [トピック ARN] で、次の Amazon Resource Name (ARN) をコピーします。

      arn:aws:sns:us-east-1:745490931007:atlassian-public-ip-changes

   2. [プロトコル] で、次のサポート対象プロトコルのいずれかを選択します。

      http https sqs lambda firehose

   3. In Endpoint, type the endpoint to receive the notification.

   4. [Create subscription (登録の作成)] を選択します。

6. You’ll be contacted on the endpoint that you specified and asked to confirm your subscription.

Notifications are subject to the availability of the endpoint. You may want to check the JSON file periodically to ensure that you have the latest ranges.

If you no longer want to receive these notifications, you can unsubscribe.

Unsubscribe from notifications for Atlassian IP ranges

1. Amazon SNS コンソール (https://console.aws.amazon.com/sns/v3/home) を開きます。

2. In the navigation pane, select Subscriptions.

3. Select the checkbox for the subscription.

4. Select Actions, then Delete subscriptions.

5. 確認を求められたら、[削除] を選択します。

IPv6 をサポートしていますか?

Yes, but our egress proxies will attempt to connect to the A record for the DNS name you provide before trying the AAAA record. In practice, we will use IPv6 only if your service is setup as IPv6 only. Full list of IPv6 ranges is available at https://ip-ranges.atlassian.com.

文書化された範囲外の IP アドレスからの接続試行があります。どうしたらよいでしょうか?

Submit a support ticket to let us know about this issue. Possible reasons for this may be:

• As Atlassian combines apps, some functionalities may have different infrastructure deployment footprint, which may mean some traffic will originate from new regions.

• Third-party app integrations may open connections from their own infrastructure, which is outside of Atlassian’s control. Refer to the vendor’s documentation and support team for more information.

https://ip-ranges.atlassian.com/ に挙げられている項目が多いのはなぜですか?

The list at https://ip-ranges.atlassian.com is created for machine consumption and covers all Atlassian apps for traffic from Atlassian cloud to self-hosted products and services, as well as connections from users to Atlassian cloud.

We plan to add tagging to the ranges so they can be filtered to only show the relevant ranges for each situation based on app, direction of connection, IP family, region etc.

The current IP range to enable for the migration assistants to work as expected is too wide. What are the exact Atlassian API addresses (URLs) to allow for the plugin to work?

You must allow the URLs below for the migration assistants to work. The URLs listed are subject to change and new URLs may be added. We encourage you to monitor this page for the latest changes.

If any of the listed hosts send client-side redirects to other domains (now or in the future), then we’ll remove them from the list.

For Confluence Cloud Migration Assistant communication

For Jira Cloud Migration Assistant communication

For Bitbucket Cloud Migration Assistant communication