Network and Connectivity Troubleshooting Guide

confluence.atlassian.com/kb/network-and-connectivity-troubleshooting-guide-720405335.html

This page is a part of our Application Links Troubleshooting Guide.

The first part of this page describes the specific network and connectivity errors that can
be diagnosed automatically by application links and the actions you can take to correct
those errors.

The second part provides a general troubleshooting guide to help you identify and
correct network and connectivity errors that may occur when using application links.

On this page:

Common network and connection errors

Unable to reach the remote application

The application link was attempting to connect to the remote application but the
hostname of the remote application couldn't be resolved.

You may see this error message in the Atlassian application logs:

java.net.UnknownHostException: Unable to resolve host

Possible causes Actions you can take

Misconfigured DNS. Check your DNS configuration, particularly for

private networks.

See nslookup below.

The application URL for the
remote application is
misconfigured, or may have
changed recently.
Check the application URL of the remote
application:
Is the host name correct?
Is the port correct?
Is the context path correct?
Does the application URL match the base URL
for the remote application (or the display URL
if the remote application is behind a reverse
proxy)?

Back to top

The remote application is not responding

1/10
The application link was attempting to connect to the remote application but the
connection was refused.

You may see this error message in the Atlassian application logs:

java.net.ConnectException: Connection refused

Possible causes Actions you can take

The remote Check that the remote application is operational, by accessing it

application is from the browser using the application URL (or the display URL
down. if the remote application is behind a reverse proxy).
If the remote application is not accessible with the browser, ping
the remote application URL from the local server – the remote
application must be accessible using the application URL for the
application link to work. See ping below.

The Check the application URL configuration at the local end:

application
URL is Does the application URL use the correct port?
misconfigured. If you're using the IP address for the application URL, is that
correct?
Does the application URL match the base URL of the remote
application (or the display URL if the remote application is
behind a reverse proxy )?
Does the application URL use the correct context path?

A firewall is Check that the firewall configuration allows access on the required
blocking port, using the network tools described below.
access.

Back to top

A firewall is blocking requests

The application link was attempting to connect to the remote application but requests to
the remote application are being blocked by a firewall in your network.

You may see an HTTP 405 message in your browser.

Possible causes Actions you can take

A firewall is Check that the firewall configuration allows HTTP requests

blocking requests. (such as PUT) on the required port.

Back to top

Network request timed out

2/10
The application link was able to contact the remote application but could not establish a
connection.

You may see this error message in the Atlassian application logs:

java.net.ConnectException: connect timed out

Possible causes Actions you can take

The remote application Check that the remote application is operational, by

is in deadlock. accessing it as usual from the browser.

A firewall is blocking Check that the firewall configuration allows HTTP

requests. requests on the required port.

Back to top

Unable to locate the remote application

The application link was attempting to connect to the remote application but couldn't
even contact it.

You may see this error message in the Atlassian application logs:

java.net.NoRouteToHostException

Possible causes Actions you can take

A firewall is Check that the firewall configuration allows access on the

blocking required port.
requests. Use a tool like  traceroute , described below, to show the
path of traffic between the local and remote machines.

An intermediate Use a tool like  traceroute , described below, to show the

router is down. path of traffic between the local and remote machines.

Back to top

Network response timed out

The application link was able to establish a connection with the remote application but no
response was received.

You may see this error message in the Atlassian application logs:

java.net.SocketTimeoutException: connect timed out

3/10
 Possible causes Actions you can take

The remote application Check that the remote application is operational, by

is in deadlock. accessing it as usual from the browser.

There is a network Use the tools described below to check the connection
connection problem. with the remote machine.

Back to top

Unexpected response

The application link was attempting to connect to the remote application but an
unexpected HTTP response was received. For many cases, this indicates that the remote
application is behind a proxy that only provides HTTP 50x responses.

You may see these error messages in the Atlassian application logs:

UNEXPECTED_RESPONSE

UNEXPECTED_RESPONSE_STATUS

<response code>

<response body>

Possible causes Actions you can take

HTTP 403: Forbidden The remote application is behind a misconfigured

This usually indicates
an authentication
failure. However
application links report
authentication failures
differently from a 403,
so this suggests a
problem with the proxy
configuration instead.
proxy. Check the local application logs for the
<response body> .
If the application has been configured with an
outbound proxy, the remote application URL can
be added to the nonProxyHosts to allow the
application link to bypass it.
See How to Configure Outbound HTTP and
HTTPS Proxy for your Atlassian application
nonProxyHosts may be configured incorrectly
and non-functional. See:
Jira server ignores http.nonProxyHosts JVM
option
JAVA Option '-Dhttp.nonProxyHosts' Does
Not Work on Windows OS

HTTP 404: Page not found Check that the application URL used to configure
The application URL the application link is correct for the remote
used to configure the application.
application link is not
correct, or the
application's address
has changed.

4/10
 HTTP 405: Method not allowed
A firewall or proxy is
preventing HTTP
requests.
HTTP 500: Internal server error
The remote application
may not be behind a
proxy, but the
application may have
an error, such as an
out of memory error.
HTTP 503: Service unavailable
The remote application
is behind a proxy and
is down.
HTTP 504: Gateway timeout
The remote application
is behind a proxy and
has timed out.
No status, or a different status
from any of the above
Back to top
Troubleshoot general connection errors with application links
Use the general troubleshooting guide below to help solve application links connection
problems that are not covered by the common error types above.
Possible cause
Check the firewall or proxy configuration to see if
HTTP requests (such as PUT) are allowed on the
required port.
See A firewall is blocking requests above.
Check that the remote application is operational,
by accessing it as usual from the browser.
Check the application error logs.
Check that the remote application is operational
by accessing it directly from your browser.
Restart the remote application, or contact your
administrator.
See The remote application is not responding
above.
Try again later.
Check that the remote application is operational,
by accessing it as usual from the browser.
Restart the remote application if necessary, or
contact your administrator.
The remote application is behind a misconfigured
proxy. Check the local application logs for the
<response body> .
The remote application is not actually of the type
selected when configuring the application link.
Check that the Application Type for the
application link matches the remote application
type. If it doesn't, you'll need to recreate the
application link, making sure to choose the correct
option for Application Type. See Link Atlassian
applications to work together.
Action you can take
5/10
 The server that hosts the application is not Check that the remote server is
running. actually running.

One or both servers are not actually Check that you can reach each
connected to the network. server by pinging each server
from the other. See ping below.

The server that hosts the application is Check the connector directive
running, but it is not listening on the port that in the server.xml configuration
the application is trying to connect to. file for the remote application.
See our Reverse Proxy and

Application Link Troubleshooting

Guide.

A firewall or other network device is blocking Use telnet to test that the remote
connections using the particular combination server accepts connections on a
of host address and port. specific port.

The address and port combination for the Check the current location of the
server that hosts the remote application is remote server.
incorrect or has changed.

The protocol being used to make the Check the connector directive
connection is incorrect (for example, it uses in the server.xml   configuration
HTTP instead of HTTPS). file for the remote application.

Error messages in the logs

You may see these error messages in the application logs (or the browser window for the
HTTP messages):

java.net.ConnectException: Connection refused

java.net.ConnectException: Connection timed out

java.net.NoRouteToHostException

java.net.SocketTimeoutException: Connection timed out

java.net.UnknownHostException: Unable to resolve host

HTTP 405 error message in browser

HTTP 503 error message in browser

Follow a link above for detailed information on this page.

6/10
Application log locations

Collapse

Logging
configuration Application logs Tomcat webserver logs

Bamboo <Bamboo installation  

directory>
/logs

Bitbucket <Bitbucket home <Bitbucket Server

Server / directory>/log installation directory>/logs
Stash
<Stash home directory>/log <Stash installation
directory>/logs

Confluence <Confluence home <Confluence installation

directory>/logs directory
>/logs

Crowd <Crowd home <Crowd installation

directory>/logs directory>/apache-tomcat/logs

Crucible <Crucible installation  
 directory>/var/log/

Fisheye <FishEye installation  
 directory>/var/log/

JIRA <JIRA application home <JIRA application

applications directory>/log installation directory>/logs

Consider enabling the DEBUG level of logging on the application to get more detailed logs
– DEBUG adds all stack traces, and includes HTTP response messages.

Server.xml locations

Collapse
The location of your server.xml file depends on your application, operating system,
and installation location. 
Common default installation locations for Atlassian applications are:

Linux:  /opt/atlassian/<application-name>
Windows:  C:\Program Files\Atlassian\<application-name>
Windows:  C:\Atlassian\<application-name>

Locations in Atlassian application's folder structure:

Application server.xml location

Bamboo <install-path>/conf/

7/10
 Confluence <install-path>/conf/

Crowd <install-path>/apache-tomcat/conf/

Crucible As for Fisheye.

Fisheye The Fisheye configuration file is config.xml , see Configuring the

Fisheye web server and How to enable Fisheye/Crucible to listen to
web requests on additional ports.

JIRA <install-path>/conf/
applications

Bitbucket N/A, replaced by  <Bitbucket home

Server 5.0 directory> /shared/bitbucket.properties

Please read through Migrate server.xml customizations to

bitbucket.properties

Bitbucket <Bitbucket home directory>   /shared/server.xml

Server 4.0 –
 4.14

Stash 3.8 – <Stash home directory>/shared/

 3.11

If you are on any of these later releases but your server.xml does
not exist in the directory above, it means that you are running from the
<install-path>/conf/server.xml .

We recommend that you copy <install-path>/conf/server.xml

into <Stash home directory> /shared/ that way you won't need
to worry about this when you upgrade your instance.

Stash 3.7 <install-path>/conf/

and earlier

<install-path>  refers to where the application was installed on your system.

Network connection tools

You can test the network connection between two machines using the tools described
below. The objective is to check that:

Each machine can communicate with the other.

The required ports are open and connections can be made to them.
Each application is able to communicate with the other using a particular
hostname/address and port combination.
Any firewalls or other network devices between each application have been
configured to permit traffic between them.

8/10
Alternatively, you may wish to bypass certain network configurations and create
an unproxied application link.

Collapse
The ping command sends a small packet to the destination address, and notes the time
it takes to respond. You can use ping to check the following:

Network connection - if ping succeeds, then both machines are connected to the
network.
Correct DNS resolution - does the hostname (such as atlassian.com
) resolve to
an IP address, and is it the correct one?
Response time between the machine issuing the ping, and the destination. Lower
response times are better.

Failure to respond to a ping isn't necessarily an indication that the server is offline or
down – it simply may not be responding to ping requests.

Collapse
The traceroute ( tracert on Windows) command shows the flow of traffic between
the current machine and the destination. Trace routes are particularly effective at
identifying segments of poor performance or congestion.

Collapse
The telnet command can be used to test that a host accepts a connection on a specific
port. The telnet command is typically used like this:

telnet <host> <port>

Example:

telnet atlassian.com 80

When successfully connected to a host on the specified port, the output is similar to the
following:

telnet host.example 80

Trying 192.168.1.100...

Connected to host.example.

Escape character is '^]'.

Once connected to the host and specified port, you can exit the telnet session. The
purpose is to ensure you can connect over the specified port. Firewalls or other network
configurations will reject the connection.

Telnet is not installed by default on Microsoft Windows.

Use "Turn Windows features on or off" in Windows 7 to install Telnet

In Server editions of Windows, use "Server Manager" to install Telnet

9/10

Collapse
The nslookup command is used for querying the Domain Name System (DNS) to obtain
domain name or IP address mappings. It allows you to check if the remote server's DNS
name can be resolved from the local server.

Typically, you run nslookup from each server and check that the correct IP address for
the other server is returned.

If the remote DNS name can't be resolved you'll need to get the DNS entry for each server
updated.

If your servers connect over HTTPS you may need to consider updating the host address
common name for your SSL certificates as well.

Last modified on Oct 2, 2018

Was this helpful?

Yes
Provide feedback about this article
Powered by Confluence and Scroll Viewport.

10/10