It seems that a lot of programs are designed to read these environment variables to decide what proxy to go through in order to connect to a resource on the internet. Those programs may also have their own, individual proxy settings, but if those are not set, they'll happily use these environment variables...


I just want to know:

  • Are these environment variables standard?
  • Is there a written specification (may be by the OS manufacturers?) that recommends the use of these environment variables?
  • 1
    I do not know no_proxy, but http_proxy (written lowercase ) is standard
    – Uwe Burger
    Jul 24, 2015 at 20:21
  • @UweBurger perhaps you can state which programs use it.. And that goes for the questioner too. I've seen it used on wget
    – barlop
    Jul 25, 2015 at 3:23
  • Documented (in a wiki) for Arch Linux: wiki.archlinux.org/… Jun 29, 2020 at 1:33
  • They are a de facto standard. Despite their unixy origin, even .NET uses them. There is some variability in the details of their support, though, as the excellent accepted answer explains.
    – Palec
    Feb 8 at 18:41

3 Answers 3


I agree with BillThor's statement that This is more a convention than a standard.
I don't know the origin of these variables but in case of HTTP on *nix many conventions seem to originate from behavior of libcurl HTTP library and curl command line program.

At https://curl.haxx.se/docs/manual.html there's description of environment variables related to using HTTP proxy which libcurl/curl understands:


Curl reads and understands the following environment variables:

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)

If the host name matches one of these strings, or the host is within the domain of one of these strings, transactions with that node will not be proxied.

Please notice that http_proxy is spelled lowercase as the only one among these variables. Some libraries/programs look for lowercase names of these variables whereas others look for upppercase names. To be safe one should define both lowercase and uppercase versions of each variable.

Another issue is that cited description of how host names are matched against NO_PROXY is not precise and does not answer the following questions:

  • Should values be fully qualified domain names (FQDN) thus ending with a dot like foo.example.com. or not?
  • Should foo.example.com match only this one domain or should it also match any subdomain like bar.foo.example.com? If the latter then should it also match any subdomain in any subdomain like bar.baz.foo.example.com?
  • Is .foo.example.com (dot at the beginning) allowed and if so then what should it match ?
  • Is asterisk (*) allowed as part of value (*.example.com, *example.com) and if so then how is it treated?

Lack of formal specification leads to confusion and bugs. Here one has to mention libproxy library which aims to provide correct and consistent support for proxy configuration. From project's home page:

libproxy exists to answer the question: Given a network resource, how do I reach it? It handles all the details, enabling you to get back to programming.

Further reading:


This is more a convention than a standard. It is likely supported by one or more protocol handler libraries which actually make the connections. Java uses similar properties in its protocol libraries.

Understanding and using common conventions makes development much simpler. It also helps implement the principle of least surprise and make programs more likely to just work.


There is no real standard.

Different tools interpret these variables similarly but subtly differently. For example the case of the recognised environment variables and the case-precedence varies between tools like curl and wget and languages like Ruby, Python and Go: (This table is taken from the excellent article We need to talk: Can we standardize NO_PROXY?)

  curl wget Ruby Python Go
http_proxy (lowercase) Yes Yes Yes Yes Yes
HTTP_PROXY (Uppercase) No No Yes (warning) Yes (if REQUEST_METHOD not in env) Yes
https_proxy (lowercase) Yes Yes Yes Yes Yes
HTTPS_PROXY (Uppercase) Yes No Yes Yes Yes
Case precedence lowercase lowercase only lowercase lowercase Uppercase

For more details (particularly about the NO_PROXY variable) and some history look at the mentioned complete article.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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