How to change gradle plugin portal from https to http

By default, gradle will request the url “”. Because my gradle is behind the corporate’s proxy and it can’t work properly in HTTPs protocol. How to change the configuration to let gradle download plugin from “”?


Currently the plugin portal forces the use of HTTPS for security reasons.

Are you able to configure your proxy settings for Gradle to use as described here?


Hi tom, thanks for your reply. I’ve apply http proxy configuration successfully. But it doesn’t work for HTTPS cause of the certification problem. So i change all my configuration to HTTP.

Sounds to me that when you say ‘certification problem’, your proxy is returning you a different page than what was expected. Whats the error message out of Gradle?
Is there a chance that your HTTPS proxy also requires some authentication information in addition to just server and port?

Hi Kon,The debug information as following:

16:43:20.774 [DEBUG] [org.gradle.internal.resource.transport.http.HttpResourceAccessor] Constructing external resource:
16:43:20.774 [DEBUG] [org.gradle.internal.resource.transport.http.HttpClientHelper] Performing HTTP GET:
16:43:20.801 [DEBUG] [org.apache.http.impl.conn.PoolingClientConnectionManager] Connection request: [route: {tls}->>][total kept alive: 0; route allocated: 0 of 5; total allocated: 0 of 10]
16:43:20.802 [DEBUG] [org.apache.http.impl.conn.PoolingClientConnectionManager] Connection leased: [id: 2][route: {tls}->>][total kept alive: 0; route allocated: 1 of 5; total allocated: 1 of 10]
16:43:20.808 [DEBUG] [org.apache.http.impl.conn.DefaultClientConnectionOperator] Connecting to
16:43:20.823 [DEBUG] [org.apache.http.client.protocol.RequestAuthCache] Auth cache not set in the context
16:43:20.825 [DEBUG] [org.apache.http.client.protocol.RequestProxyAuthentication] Proxy auth state: UNCHALLENGED
16:43:20.826 [DEBUG] [org.apache.http.impl.conn.DefaultClientConnection] Sending request: CONNECT HTTP/1.1
16:43:20.921 [DEBUG] [org.apache.http.impl.conn.DefaultClientConnection] Receiving response: HTTP/1.1 407 authenticationrequired
16:43:20.922 [DEBUG] [org.apache.http.client.protocol.ResponseProcessCookies] Cookie spec not specified in HTTP context
16:43:20.922 [DEBUG] [org.apache.http.impl.client.SystemDefaultHttpClient] Authentication required
16:43:20.922 [DEBUG] [org.apache.http.impl.client.SystemDefaultHttpClient] requested authentication
16:43:20.926 [DEBUG] [org.apache.http.impl.client.ProxyAuthenticationStrategy] Authentication schemes in the order of preference: [negotiate, Kerberos, NTLM, Digest, Basic]
16:43:20.926 [DEBUG] [org.apache.http.impl.client.ProxyAuthenticationStrategy] Challenge for negotiate authentication scheme not available
16:43:20.927 [DEBUG] [org.apache.http.impl.client.ProxyAuthenticationStrategy] Challenge for Kerberos authentication scheme not available
16:43:20.928 [DEBUG] [org.apache.http.impl.client.ProxyAuthenticationStrategy] Challenge for Digest authentication scheme not available
16:43:20.929 [DEBUG] [org.apache.http.impl.conn.DefaultClientConnection] Connection<-> closed
16:43:20.929 [DEBUG] [org.apache.http.impl.client.SystemDefaultHttpClient] CONNECT refused by proxy: HTTP/1.1 407 authenticationrequired
16:43:20.930 [DEBUG] [org.apache.http.impl.conn.DefaultClientConnection] Connection<-> closed
16:43:20.930 [DEBUG] [org.apache.http.impl.conn.PoolingClientConnectionManager] Connection released: [id: 2][route: {tls}->>][total kept alive: 0; route allocated: 0 of 5; total allocated: 0 of 10]
16:43:20.931 [DEBUG] [org.gradle.configuration.project.BuildScriptProcessor] Timing: Running the build script took 0.188 secs
16:43:20.951 [LIFECYCLE] [org.gradle.BuildResultLogger]
16:43:20.951 [LIFECYCLE] [org.gradle.BuildResultLogger] BUILD FAILED
16:43:20.952 [LIFECYCLE] [org.gradle.BuildResultLogger]
16:43:20.952 [LIFECYCLE] [org.gradle.BuildResultLogger] Total time: 3.3 secs

Thanks Savagearts

It does appear that your proxy requires authentication. (407 error)

Do you have systemProp.https.proxyUser and systemProp.https.proxyPassword in your

Make sure you have the s of https in the property name and not just http.

Also depending on the type of proxy you may have to specify your domain as well as your username. Per 20.3.1 of the user guide

For example,
systemProp.https.proxyUser=MYDOMAIN/username or

Some corporations have details of connecting to the proxy on their intranet too which may help.

Please let us know how you go


Tnanks Kon. I do add following configuration in my It works for HTTP, but not for HTTPS.

Ok cool

I’d just try a few variations without the MyDomain and alternating your backslash and forward slash separators if you haven’t already.

It may just be your proxy setup. You may be able to start a dialog with your network engineers to enable https access to by trying out some command line tools (something they can reproduce easily)

See my previous post here Cannot apply plugin with the "plugin DSL" when running behind an authenticated proxy

Good luck

Anyway thanks for your help! I’ll give your idea a try.

As I see it downloading from the plugin portal without HTTP is working fine. Try for example the URL

I am also in an environment where I can’t use HTTPS. Is there a way to switch the plugin portal’s URL from to

1 Like

I would like an answer to this as well. The problem is that CI environment we don’t want to expose a username/password, and contacting network team is not applicable for our large company.


I’m afraid there’s no way to resolve plugins over HTTP only. Any attempt to load a file over HTTP will immediately be redirected to HTTPS. This is for security, given that Gradle plugins are executable code being downloaded from the internet.

As I see it, you’ve got the following options:

  • Set up a proxy that can talk to the net over HTTPS, but doesn’t require authentication when being connected-to from your CI system.
  • Set up a local mirror based on Artifactory or Nexus that itself can talk HTTPS, but provides a HTTP endpoint for your CI systems
  • Manually download the plugins that you need and put them somewhere that your CI can access, by file share or HTTP server.

Most people go the Artifactory etc route.