Install packages behind the proxy

Hi everyone!
I try to use Julia in my current job. But have trouble with installing packages behind the proxy.
I use 1.1.0 binaries.
error massage:
julia> Pkg.add(“IJulia”)
Cloning default registries into ~/.julia
Cloning registry from “GitHub - JuliaRegistries/General: The official registry of general Julia packages
ERROR: failed to clone from GitHub - JuliaRegistries/General: The official registry of general Julia packages, error: GitError(Code:ERROR, Class:Net, curl error: Unsupported proxy ‘’, libcurl is built without the HTTPS-proxy support.
[1] pkgerror(::String) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.1/Pkg/src/Types.jl:120
[2] #clone#3(::String, ::Base.Iterators.Pairs{Symbol,LibGit2.CachedCredentials,Tuple{Symbol},NamedTuple{(:credentials,),Tuple{LibGit2.CachedCredentials}}}, ::Function, ::String, ::String) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.1/Pkg/src/GitTools.jl:111
[3] (::getfield(Pkg.GitTools, Symbol(“#kw##clone”)))(::NamedTuple{(:header, :credentials),Tuple{String,LibGit2.CachedCredentials}}, ::typeof(Pkg.GitTools.clone), ::String, ::String) at ./none:0
[4] (::getfield(Pkg.Types, Symbol(“##87#89”)))(::LibGit2.CachedCredentials) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.1/Pkg/src/Types.jl:1103
[5] shred!(::getfield(Pkg.Types, Symbol(“##87#89”)), ::LibGit2.CachedCredentials) at ./secretbuffer.jl:184
[6] clone_or_cp_registries(::Pkg.Types.Context, ::Array{Pkg.Types.RegistrySpec,1}, ::String) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.1/Pkg/src/Types.jl:1102
[7] clone_or_cp_registries at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.1/Pkg/src/Types.jl:1087[inlined]
[8] clone_default_registries() at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.1/Pkg/src/Types.jl:1037
[9] find_registered!(::Pkg.Types.EnvCache, ::Array{String,1}, ::Array{Base.UUID,1}) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.1/Pkg/src/Types.jl:1312
[10] registry_resolve!(::Pkg.Types.EnvCache, ::Array{Pkg.Types.PackageSpec,1}) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.1/Pkg/src/Types.jl:949
[11] #add_or_develop#15(::Symbol, ::Bool, ::Base.Iterators.Pairs{Union{},Union{},Tuple{},NamedTuple{(),Tuple{}}}, ::Function, ::Pkg.Types.Context, ::Array{Pkg.Types.PackageSpec,1}) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.1/Pkg/src/API.jl:47
[12] #add_or_develop at ./none:0 [inlined]
[13] #add_or_develop#14 at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.1/Pkg/src/API.jl:31 [inlined]
[14] #add_or_develop at ./none:0 [inlined]
[15] #add_or_develop#13 at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.1/Pkg/src/API.jl:29 [inlined]
[16] #add_or_develop at ./none:0 [inlined]
[17] #add_or_develop#12(::Base.Iterators.Pairs{Symbol,Symbol,Tuple{Symbol},NamedTuple{(:mode,),Tuple{Symbol}}}, ::Function, ::String) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.1/Pkg/src/API.jl:28
[18] #add_or_develop at ./none:0 [inlined]
[19] #add#20 at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.1/Pkg/src/API.jl:59 [inlined]
[20] add(::String) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.1/Pkg/src/API.jl:59
[21] top-level scope at none:0

1 Like

Many corporate proxies actually work over HTTP, not HTTPS; your communication is still secure because proxied https traffic uses the CONNECT method and the TLS handshake is still handled between the client and upstream server (i.e. without proxy interception).

So unless your employer has told you otherwise, it’s worth checking whether setting the https_proxy= works for you.

PS. If you have issues with command-line applications and proxies, this project may be for you.

Yes, I agree with @tkluck.

You can add these lines to ~/.julia/config/startup.jl , which will execute on each new Julia session:


Thanks for the fast reply. I have the opportunity to use a proxy without https. I try to use your advice with startup.jl, before that I erase all proxy env vars, but Julia still finds proxy somewhere. And error still the same.

Can you execute this line just before trying to add a package and paste the result here?

println(ENV["HTTP_PROXY"]); println(ENV["HTTPS_PROXY"])

I have a similar issue with installing packages behind a proxy. But in my case it’s not complaining about HTTPS proxies or whatever, it’s just trying to direct connect and failing (which is expected if it tries to direct connect)

I’m using the Debian testing packages: Julia 1.0.3+dfsg-4

I have all the right ENV settings:

julia> ENV["HTTP_PROXY"]

julia> ENV["http_proxy"]


julia> ENV["https_proxy"]

I try to Pkg.add(“StatsBase”) but rather than complaining about anything related to the proxy, it actually just tries to direct connect, which isn’t possible:

julia> Pkg.add("StatsBase")
   Cloning default registries into /home/dlakelan/.julia/registries
   Cloning registry General from ""
e[?25le[?25hERROR: failed to clone from, error: GitError(Code:ERROR, Class:OS, failed to connect to Connection timed out)
 [1] pkgerror(::String) at /build/julia-wJr69F/julia-1.0.3+dfsg/usr/share/julia/stdlib/v1.0/Pkg/src/Types.jl:120


1 Like

I think you need to configure the proxy on the .gitconfig file

Try adding

        proxy = http://pico.lan:3128

In my case it works


I just tried disabling both lines and the package manager is still working. I think there is some other issue. A colleague of mine is experiencing the same problem. I will try to dig deeper.

Git works fine without that line, but I put it in anyway, and Julia has the same results… :face_with_raised_eyebrow:

Ok, I tried just git cloning the JuliaRegistries/General.git by hand, and then after that it seemed to work, so something about the initial getting of the registries is different from getting individual packages!

Further useful info: I installed the 1.1.0 binaries from instead of the Debian packages, and they seem to behave better. So probably the solution is to use newer Julia.

Thanks, this answer solved the problem for me.


I wanted to add one more thing, should anyone encounter this problem. You can handle even authenticated proxies by adjusting the global .gitconfig or using a tool like CNTLM. But in my case, CNTLM didn’t solve the problem of downloading binaries (most trivial example would be Plots, which involves downloading .zip files).
This was worked around by using a slightly modified BinaryProvider.jl. I’m not sure how this fork will be kept updated, for the moment it works.

It looks like that change was merged in July:

and should be part of the released versions from then.

I didn’t notice it, but this is great news, thank you!

if you are using proxy, add these two lines to C:\Julia\etc\julia\startup.jl file:

ENV["HTTP_PROXY"] = " port"
ENV["HTTPS_PROXY"] = " port"

I set the environment as this and still meet this problem.
Does this fixed your problem

On Debian Buster I had to set the Git proxy in /etc/gitconfig

	proxy = http://<proxyserver>:<proxyport>/

The important part is to not leave out the trailing slash on this line!

You will also need to set the http"s" proxy.


By doing this, would it solve your problems?

I’ll like to report that I’m having similar issues when trying to install packages behind a corporate proxy. I’m using Julia 1.5 on Windows 10 and already defined our proxies as given by the IT guys (already have used them on Python and R).
What seems strange is that one of the errors I get seems to be related with PowerShell:

ProcessFailedException(Base.Process[Process(`powershell -NoProfile -Command '[System.Net.ServicePointManager]::SecurityProtocol =

Any idea of how to overcome this?


Setting http proxy and https proxy environment variables should do it.
Also, to install packages, makje sure that * is whitelisted. (the *. in the beginning is important since the redirects you based on your geo location so by this you’re allowing all geological servers).
The setting of necessary variables can be seen e.g. here in order to make child process in CompatHelper work behind corporate firewall.