Configure an outbound proxy for use in Jira server
Platform Notice: Server and Data Center Only - This article only applies to Atlassian products on the server and data center platforms.
The content on this page relates to platforms which are not supported for JIRA Applications. Consequently, Atlassian cannot guarantee providing any support for it. Please be aware that this material is provided for your information only and using it is done so at your own risk.
- This Outbound Proxy configuration only works for HTTP and HTTPs request only. If you are trying to connect JIRA to a Mail Server (Gmail or Office365) or to an LDAP Server, this configuration will not work.
https.proxyHostproperty can not be used in combination with the
socksProxyHostproperty. (Not supported by the outgoing httpclient and will lead to unexpected results)
This page defines how to configure JIRA applications such that they can communicate externally through an outbound proxy. This is required to access servers outside the network it's hosted in, such as the Atlassian Marketplace. If you wish to host JIRA applications behind a reverse-proxy (or inbound proxy), please refer to Integrating JIRA with Apache or Integrating JIRA with Apache using SSL.
Adding JVM properties
All properties discussed in this article are Java Virtual Machine (JVM) parameters. This article covers the properties needed for proxy configurations, but not where to put them.
JVM properties are set in setenv scripts
To add the parameters to Jira's JVM:
- Modify the relevant startup script (setenv.sh/setenv.bat)
- Restart Jira
For complete instructions on the process of adding properties to the JVM on startup, please see our Setting Properties and Options on Startup documentation. This documentation also explains how to verify the settings have taken effect.
Proxy Support is configured in JIRA applications by passing certain system properties to the Java Virtual Machine (JVM) on startup. These properties follow the conventions defined by Oracle:
http.proxyHost property must be defined to configure an HTTP proxy, and
https.proxyHost for an HTTPS proxy.
http.proxyPort properties indicate the proxy server and the port that the HTTP protocol handler will use. For example:
-Dhttp.proxyHost=proxy.example.org -Dhttp.proxyPort=8080 -Dhttps.proxyHost=proxy.example.org -Dhttps.proxyPort=8080 -Dhttp.nonProxyHosts=localhost
http.nonProxyHosts indicates the hosts which should be connected to directly and not through the proxy server. The value can be a list of hosts, each separated by a ( | ), and in addition a wildcard character ( * ) can be used for matching. For example:
The pipe character ( | ) may need to be escaped in Linux
The pipe character ( | ) may not work in the latest versions of Windows with the latest Windows update
Please refer to JAVA Option '-Dhttp.nonProxyHosts' Does Not Work KB article for more details.
http.nonProxyHosts property is not configured, all web requests will be routed through the proxy. For example, if connecting Confluence and JIRA applications together with Application Links, we would recommend bypassing the proxy and communicating on the internal network with this property. Routing through the proxy can have ramifications when taking into account IP validation on those links - the source IP of the server can be different depending on how the traffic is routed.
At the minimum, the http.nonProxyHosts must include localhost and JIRA baseurl, otherwise certain functionality may not properly work (JIRA tries to connect to itself and HTTP request can timeout or be blocked by proxy). For example:
If connecting JIRA applications to any other applications, the application URL should be added to the
nonProxyHosts argument. Otherwise what can happen is when JIRA applications attempt to talk to another Atlassian application the HTTP request can timeout, or not resolve. This will prevent the applications from linking. For example when connecting JIRA applications to Confluence (located on confluence.atlassian.com):
Proxy authentication is configured by passing the below properties to Java, as in our Setting Properties and Options on Startup documentation.
-Dhttp.proxyUser=atlaspirate -Dhttp.proxyPassword=yarrrrr -Dhttps.proxyUser=atlaspirate -Dhttps.proxyPassword=yarrrrr
Microsoft ISA NTLM Authentication
As in our JIRA is Unable to Use NTLM Authentication KB article, JIRA applications do not currently support all configurations of NTLM authentication. However, to configure this with the JVM, the below property is used:
Configuring Authentication Order
There are three authentication mechanisms provided -
basic in that order by default. It is possible to change the order and also not exclude one or more methods altogether. This can be done with the following property.
In this example, the authentication order will be
basic and then
ntlm only -
digest will not be used.