I've encountered both http_proxy and HTTP_PROXY. Are both forms equivalent? Does one of them take precedence over the other?


There is no central authority who assigns an official meaning to environment variables before applications can use them. POSIX defines the meaning of some variables (PATH, TERM, …) and lists several more in a non-normative way as being in common use, all of them in uppercase. http_proxy and friends isn't one of them.

Unlike basically all conventional environment variables used by many applications, http_proxy, https_proxy, ftp_proxy and no_proxy are commonly lowercase. I don't recall any program that only understands them in uppercase, I can't even find one that tries them in uppercase. Many programs use the lowercase variant only, including lynx, wget, curl, perl LWP, perl WWW::Search, python urllib/urllib2, etc. So for these variables, the right form is the lowercase one.

The lowercase name dates back at least to CERN libwww 2.15 in March 1994 (thanks to Stéphane Chazelas for locating this). I don't know what motivated the choice of lowercase, which would have been unusual even then.

  • 1
    Unlike basically all conventional environment variables used by many applications, http_proxy, https_proxy, ftp_proxy and no_proxy are commonly lowercase. I don't recall any program that only understands them in uppercase -> For the record, I just found out that docker 17.04.0-ce only honors NO_PROXY. – jaume Nov 29 '17 at 7:50
  • cloudformation scripts (cfn-signal, cfn-init) use the uppercase variant HTTPS_PROXY. docker also uses the uppercase variant. – Felipe Alvarez Oct 9 '18 at 5:24

There is no standard and both uppercase and lowercase versions are used depending on the application (also see HTTPS_PROXY, ALL_PROXY, NO_PROXY).

For example:



  Curl reads and understands the following environment variables:

        http_proxy, HTTPS_PROXY, FTP_PROXY

  They should be set for protocol-specific proxies. General proxy should be
  set with


  A comma-separated list of host names that shouldn't go through any proxy is
  set in (only an asterisk, '*' matches all hosts)



   Override the HTTP proxy, normally configured using the http_proxy, https_proxy, 
   and all_proxy environment variables (see curl(1)). [..]


urllib.request.getproxies() supports both lowercase and uppercase variants.

It also mentions a security issue:

If the environment variable REQUEST_METHOD is set, which usually indicates your script is running in a CGI environment, the environment variable HTTP_PROXY (uppercase _PROXY) will be ignored. This is because that variable can be injected by a client using the “Proxy:” HTTP header. If you need to use an HTTP proxy in a CGI environment, either use ProxyHandler explicitly, or make sure the variable name is in lowercase (or at least the _proxy suffix).

Some applications allow NO_PROXY to contain stars/ip-ranges while others do not.


export https_proxy=$http_proxy HTTP_PROXY=$http_proxy HTTPS_PROXY=$http_proxy NO_PROXY=$no_proxy

should have you covered.


The convention is to use all capps environment variables when exporting them, so that when you are writing shell scripts you can use lowercase variable names without worrying about name collisions with other programs. Of course this is a convention only, there is no technical restriction on limiting the names of environment variables so the lowercase version could be used in some cases, but best practice is upper case, and remember that they are case sensitive so they could have different values.

  • Unlike most (basically, all) conventional environment variables, http_proxy and its siblings are usually lowercase. – Gilles Jun 29 '15 at 22:42
  • @Gilles that would be a bug. – hildred Jun 29 '15 at 23:19
  • 3
    No, it isn't. You're right that there's a convention to use uppercase for environment variables, but it's only a convention, not an absolute rule. The de facto standard for the environment variables http_proxy and friends is to be spelled in lowercase, in violation of a convention. For an application to use HTTP_PROXY would be a bug because it would be incompatible with the rest of the world. – Gilles Jun 29 '15 at 23:37
  • 1
    snarf requires uppercase and there is a bug report against wget. – hildred Jun 30 '15 at 0:06
  • 1
    That's backward. When a behavior has been in place for 20 years, right or wrong, that's how it is and it isn't going to be changed. I think the pioneer was lynx (it's older than the web); I don't know why it used lowercase. Curl started out as uppercase then changed to lowercase for compatibility with lynx and wget. – Gilles Jun 30 '15 at 0:11

WGET - is only using the lowercase proxy settings!


Both http_proxy and HTTP_PROXY should work on RHEL and ubuntu based systems.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.