Jira server Base URL health check fails


アトラシアン コミュニティをご利用ください。


プラットフォームについて: Server および Data Center のみ。この記事は、Server および Data Center プラットフォームのアトラシアン製品にのみ適用されます。

Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.

*Fisheye および Crucible は除く


The Base URL Health Check ensures that Jira can access its own Base URL. In Jira 7.1 and above, gadget charts are created using Javascript in the browser instead of server-side with Java. This change resulted in significant performance improvements because the server no longer has to process everything, and the browsers can handle some of it. As a result, Jira now requires that the server can connect to itself, which is different from how it operated previously.


Gadget titles showing as __MSG_gadget.xxxxxxx, __MSG_gadget.activity., __MSG_gadget.filter, _MSG_gadget.project.title_  and so on, as per the example below:




Jira can access itself through the configured Base URL

Your dashboard gadgets should be generated and loaded correctly.

Jira is not able to access itself through the configured Base URL. This is necessary so that dashboard gadgets can be generated successfully. Please verify the current Base URL and, if necessary, review your network configurations to resolve the problem.

Your dashboard gadgets may not be loading correctly. Please follow the diagnosis and resolution steps below to resolve the problem.



  • iptables80 から 8080、443 から 8443 にパケットを転送するよう設定されている
  • From the Jira server itself, try curl -v <baseurl> to verify if JIRA is able to communicate with itself.
  • Run SSLPoke from the Jira server itself and see if it returns successfully.
  • Additionally, run the httpclienttest from the Jira server itself to confirm if the SSL configuration is okay.
  • There are application links configured on the instance but they seem to be having issues.
  • As the symptoms for both environments are different, diagnosis and resolution steps are segregated into multiple sections below.
  • Entries have been configured in the hosts file.

When accessing the Dashboard, the gadgets serve a response that is processed by the client (ie the browser) to generate gadgets. While this happens, the server also connects to itself to provide the gadget's translated strings. Jira uses the URL the instance is connected to, so the Jira instance needs to be able to access itself.


  1. The user sends a request to Jira on loading the Dashboard
  2. Jira will perform a call towards itself through the gadget URL.
  3. Jira replies with the completed page and gadget's translated strings

1. The user sends a request to Jira on loading the Dashboard
2. Proxy forwarded this request to Jira
3. Jira will perform a call back to itself through the gadget URL to get the gadget's title. Performing requests to Proxy
4. Proxy forwarded this request back to Jira itself to provide the gadget's translated strings
5. Jira replies gadget's translated strings to the proxy
6. Proxy forwarded this accordingly to Jira
7. Jira replies with the completed page to proxy
8. Proxy forwarded this accordingly to use


  • Basic or certificate-based auth on a proxy layer that Jira is behind
  • ドメイン名の解決不可
  • Jira is served on an IP that's in a separate restricted subnet to the server Jira is running on
  • Jira が自己署名証明書で提供されているが、これが自身の証明書ストアに存在しない
  • There are more than 3 redirects between the entry point and the final Jira server (this is tested in the base URL check and also configured in our gadgets).

The recommended best practice is to have Jira served on one domain name only. This can have different IPs (for example internal and external) configured by different DNS, however will only resolve to one domain. For example, https://jira.atlassian.com has an external IP of (mapped to by external DNS) and an internal IP of (mapped with an internal DNS). It has one certificate for that FQDN, and all users access it on that domain only.

 Additionally, there are some environmental-specific causes of this problem. Please see below for further information.


原因 1:  

SSL を設定済みの Jira アプリケーション

atlassian-jira.log ファイルに次の情報が表示されます。

2016-02-26 14:22:28,843 http-bio-8443-exec-11 ERROR admin 862x395x1 m32d6k xx.xx.xx.xx /secure/MyJiraHome.jspa [c.a.g.r.internal.http.HttpClientFetcher] Unable to retrieve response
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
	at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)Cause
2022-03-29 23:14:36,116-0700 HealthCheck:thread-1 ERROR ServiceRunner     [c.a.t.j.healthcheck.support.GadgetFeedUrlHealthCheck] An error occurred when performing the Gadget feed URL healthcheck
javax.net.ssl.SSLException: Connection reset
	at sun.security.ssl.Alert.createSSLException(Alert.java:127)
	at sun.security.ssl.TransportContext.fatal(TransportContext.java:324)
	at sun.security.ssl.TransportContext.fatal(TransportContext.java:267)
	at sun.security.ssl.TransportContext.fatal(TransportContext.java:262)
	at sun.security.ssl.SSLTransport.decode(SSLTransport.java:135)


  1. Verify that the Root and Intermediate CA certificates were added to the keystore when SSL was configured.
  2. Follow our instructions in our Unable to connect to SSL services due to "PKIX Path Building Failed" error knowledge base article for additional details to resolve the problem.
  3. Restart JIRA (if Data Center, restart all nodes one by one)
  4. Additionally, verify the configuration with httpclienttest as described in the readme of that repository, to gather more detail.

Cause 2: Jira Applications with port forwarding configured

This applies to environments that are using port forwarding, such as iptables:


If port forwarding has been configured to forward packets from 80 to 8080 and/or 443 to 8443, you may see gadget titles be broken and show as __MSG_gadget.xxxxxxx.  This can happen if the rules are configured only to forward packets from external sources.  


You need to create a rule both for packets coming from external IP sources AND for local packets.

For example, in iptables, it should look like this:

iptables -t nat -I OUTPUT -p tcp -o lo --dport 80 -j REDIRECT --to-ports 8080

For firewalld:

firewall-cmd --permanent --add-masquerade
firewall-cmd --permanent --add-forward-port=port=80:proto=tcp:toport=8080

In Windows, we can use the netsh command, like this:

netsh interface portproxy add v4tov4 listenport=80 connectport=8080

Cause 3: Jira applications with a broken Proxy configuration

This applies to environments configured to use a Web Proxy. This can be determined by checking the "JVM Arguments" in the System Information screen for existing proxy configurations.


Jira is unable to communicate with itself due to a Web Proxy not being able to correctly resolve the Jira server.


Add the Jira server's hostname/ to the -Dhttp.nonProxyHosts and -Dhttps.nonProxyHosts arguments as in Configure an outbound proxy for use in Jira server.

Make sure that the same domain is not being mentioned twice in an argument, e.g. - Dhttps .nonProxyHosts = jira|confluence|jira

Cause 4: Jira configured with Apache in front with BasicAuth password restriction


Jira is unable to communicate with itself due to a Web Proxy requiring authentication.

不具合として次のチケットが起票されています。 JRA-61273 - Getting issue details... STATUS


Add the server IP itself for access without a password:

Order Allow, Deny
Allow from <hostname>
Satisfy Any

ソリューション 2

Shibboleth 認証を使用している場合、次の手順を実行します。

  1. /rest URL を Shibboleth 認証の外部に設定します。
  2. /rest URL は Shibboleth の保護対象外である必要があります。
  3. 例:
<LocationMatch "^(/rest)/[^/]+">
AuthType None
Require all granted

<LocationMatch "/">
AuthType Shibboleth
ShibRequireSession On
require valid-user
ShibUseEnvironment On
Order allow,deny
Allow from all
説明 The Base URL Health Check verifies if Jira is able to access its own Base URL. Starting in Jira 7.1, gadget charts are generated using Javascript in the browser rather than server-side with Java. This had significant performance improvements as the server was offloading processing to the browsers resulting in less CPU usage. Part of the change modified the way Jira previously operated, and now it is required that the server can connect to itself.
プラットフォームServer、Data Center

Cause 5: Entries have been configured in the hosts file


Sometimes after server migrations, some errors are shown when there's no DNS in function and an entry is not properly configured in the hosts file.

HealthCheck:thread-3 ERROR [c.a.t.j.healthcheck.support.GadgetFeedUrlHealthCheck] An error occurred when performing the Gadget feed URL healthcheck
org.apache.http.conn.ConnectTimeoutException: Connect to FQDN:443 [FQDN/OLD_IP] failed: connect timed out


Check the hosts file in your server and update the IP:

  • Linux: /etc/hosts
  • Windows: C:\Windows\System32\drivers\etc\hosts

Cause 6: Incorrect Traffic Shaping on Reverse Proxy or LB for REST API calls


While taking advantage of traffic shaping, customers configure the load balancer to identify all external REST API traffic and send it to a dedicated node. While doing this an incorrect configuration of sending all /rest traffic to a single node will cause background rest calls in Jira pages to be directed to that node. This will cause errors when this dedicated Jira REST API node is not up and running. 

Atlassian Data Center を使用したトラフィック分布


While doing traffic shaping only configure M2M REST API Calls to the dedicated node, and ensure end-user API calls continue using the same node that user has logged in initially.

原因 7:


"Netscape Certificate Type" Field in the Certificate is only filled with "SSL Client" Type

2022-02-23 00:11:38,543+0000 HealthCheck:thread-7 ERROR [c.a.t.j.healthcheck.support.GadgetFeedUrlHealthCheck] An error occurred when performing the Gadget feed URL healthcheck
javax.net.ssl.SSLHandshakeException: Netscape cert type does not permit use for SSL server


Used Certificate must have set the "Netscape Certificate Type" Field to
SSL Server
SSL Client

最終更新日 2024 年 4 月 29 日


Powered by Confluence and Scroll Viewport.