Configuring Developer Tools Behind a Corporate Proxy

There is a specific kind of confusion that belongs to your first week at a large company.

The browser works, so you assume the network is fine. Then git clone hangs, npm install times out, your IDE cannot check for updates, and the emulator behaves as though the network does not exist.

The usual explanation is a corporate proxy, and the reason it produces such a strange experience is that the browser was configured for it automatically and almost nothing else was.

Many companies have no proxy at all, so it is worth checking before you change anything. Run this on your work machine:

env | grep -i proxy

You might see output like this:

HTTP_PROXY=http://proxy.example.com:8080
HTTPS_PROXY=http://proxy.example.com:8080
NO_PROXY=localhost,127.0.0.1,.example.internal

If you get no output at all, your shell does not currently have any proxy-related environment variables set.

If you do see entries, HTTP_PROXY and HTTPS_PROXY tell applications which proxy server to use for outbound HTTP and HTTPS traffic. NO_PROXY lists hosts or domains that should bypass the proxy and be contacted directly. You may also see the same variables in lowercase, such as http_proxy and https_proxy; many tools recognise both forms.

What a corporate proxy actually is

A proxy is a server that sits between your laptop and the internet.

Instead of your laptop connecting directly to a website or service, it sends the request through the company proxy first. The proxy then connects to the destination on your behalf.

Companies use proxies for things such as filtering websites, logging traffic, scanning downloads, applying security rules, and controlling access to the internet.

For you, the important part is simpler: some of your tools may need to be told that the proxy exists.

Your browser might already work because your company has configured it for you. But Git, npm, Docker, package managers, IDEs, build tools, and other developer software may use their own network settings.

If one of those tools tries to connect directly to the internet when your company expects it to use a proxy, it may fail or simply sit there until it times out.

graph LR A[Your laptop] -->|configured to use| B[Corporate proxy] B -->|allowed traffic| C[Public internet] A -->|bypass list| D[Internal services] D -.->|package registry, Git server, APIs| A %% cc-caption: Traffic to the public internet goes through the proxy. Traffic to some internal services may need to bypass it.

There are a few common setups.

A forward proxy is the one you are most likely to configure yourself.

You are given a proxy address such as:

proxy.example.internal:8080

That is the hostname and port of the proxy server.

You then put that address into whatever proxy setting your tool supports. For many command-line tools, that means environment variables such as:

export HTTP_PROXY=http://proxy.example.internal:8080
export HTTPS_PROXY=http://proxy.example.internal:8080

A transparent or intercepting proxy works differently.

Your application thinks it is connecting directly to the internet, but the company network intercepts the connection along the way.

There may therefore be no proxy hostname or port for you to configure at all. env | grep -i proxy may show nothing.

This can make problems harder to recognise because your application has no idea that a proxy is involved. A failure may simply look like a normal network or certificate problem.

Some companies instead install a zero trust or secure access agent on the laptop. Products such as Zscaler, Netskope, and Cloudflare's client are examples.

These applications can route, filter, or inspect network traffic without requiring every developer tool to be configured with a traditional proxy hostname and port.

If your company uses an intercepting proxy or one of these agents, you may not need to configure a proxy address yourself.

Where the settings live, and why there are so many

Unfortunately, there is no single proxy setting that every application uses.

Your operating system may have proxy settings. Your browser may use those settings automatically.

That does not mean Git, npm, Docker, Java, Python, your IDE, or other developer tools will use them as well.

Different tools were built at different times, on different platforms, using different networking libraries. As a result, they do not all look for proxy configuration in the same place.

A common way to configure command-line tools is through environment variables:

export HTTP_PROXY=http://proxy.example.internal:8080
export HTTPS_PROXY=http://proxy.example.internal:8080
export NO_PROXY=localhost,127.0.0.1,.example.internal

HTTP_PROXY tells tools which proxy to use for HTTP requests.

HTTPS_PROXY tells them which proxy to use when accessing HTTPS destinations.

NO_PROXY lists addresses that should not use the proxy.

That last one is particularly important inside companies.

Some company services are not on the public internet at all. A company might run its own Git server, package registry, API, or development system that is only available to employees.

You might only be able to reach those services while you are in the office or connected to the company VPN.

That gives you two different routes:

github.com
your laptop → corporate proxy → public internet → github.com

git.example.internal
your laptop → company network → git.example.internal

The first request needs the proxy because it is going out to the public internet.

The second does not. The destination is already inside the company network.

NO_PROXY tells your tools which addresses belong to that second group:

export NO_PROXY=localhost,127.0.0.1,.example.internal

In this example, anything ending in .example.internal is contacted directly instead of being sent to the internet proxy.

Not every company has internal services like this, so your NO_PROXY list may be much shorter, or you may not need one at all.

Why does HTTPS_PROXY sometimes start with http://?

You may see this:

export HTTPS_PROXY=http://proxy.example.internal:8080

At first glance that looks wrong, but it is not necessarily so.

The http:// part describes where your application connects to the proxy itself.

It does not describe the final website you are visiting.

Your application may connect to the proxy over HTTP and then ask the proxy to establish a connection to an HTTPS website.

So this is quite normal:

HTTPS destination
        |
        v
HTTPS_PROXY=http://proxy.example.internal:8080

Do not change http:// to https:// just because the variable is called HTTPS_PROXY. Use the value your organisation gives you.

What about usernames and passwords?

Knowing the proxy address is only the first step. The proxy may also require you to sign in before it will let your traffic through.

How that happens depends on the tool.

Some applications show a login window when they first try to use the proxy. For example, an application might already know that the proxy is:

proxy.example.internal:8080

When it connects, the proxy asks who you are, and the application displays a username and password prompt.

Other tools have a place in their settings where you configure the proxy and, sometimes, its credentials.

Command-line tools often have no popup at all. They may rely on environment variables, their own configuration files, or authentication that your company has already set up for you.

It is technically possible to put a username and password directly into a proxy URL:

http://alice:[email protected]:8080

but this is usually best avoided because the password can end up in shell history, configuration files, logs, screenshots, or source control.

In many companies you will never type a proxy password at all. Your company login or managed laptop may authenticate you automatically.

So if you are given a proxy address but are not told anything about credentials, try the configuration your company provides first. If a tool asks you to sign in, use the authentication method your organisation specifies rather than adding your normal company password to the proxy URL.

Where you usually need to configure it

You usually do not need to configure every tool individually. What matters is knowing the broad categories where proxy settings tend to live, because that explains why one part of your setup works while another does not.

The usual places are:

This is why proxy issues feel inconsistent. You may have fixed the browser and still have a broken package manager, or fixed the IDE and still have a broken build, because each layer is reading a different setting.

I hit this with Android tooling. I had updated the IDE proxy settings and also configured the emulator, yet downloads were still failing. The missing piece was that Gradle was making its own network requests using its own configuration, so the editor looked fixed while the build remained broken. That is the pattern to watch for: one part of the toolchain works, another part fails, because they are not actually sharing the same proxy setting.

A practical approach is to start by checking the system proxy and environment variables, using a bypass list borrowed from a colleague if your team already has a working baseline. Then configure the IDE, followed by any build tools, package managers, containers, or emulators that need their own settings. Finally, test one public host and one internal host, and adjust the bypass list for the internal services you actually use.

Keep these rules in mind:

What is a PAC file?

Some organisations use a PAC file, short for Proxy Auto-Configuration file. It contains rules that decide which proxy to use for different destinations, or whether to use a proxy at all.

You may be given a URL that points to the PAC file, for example:

https://config.example.com/proxy.pac

Your company may already have configured your browser or operating system to use that URL. Simply downloading the file does nothing.

Many command-line tools do not understand PAC files directly. If you are given only a PAC URL, you may need to ask your network or IT team for the proxy hostname, port, and bypass list to use with your developer tools.

Your company may already configure all of this for you

In some organisations, proxy settings are pushed automatically to company laptops using device management or company policy.

Your browser may therefore work from the moment you sign in.

Some developer tools may also be configured automatically, while others are not.

This is why it is worth checking what already exists before adding your own configuration.

Start with:

env | grep -i proxy

Then check whether your operating system has a proxy configured and whether your company has given you a PAC URL, proxy hostname, or security agent.

If the company manages these settings centrally, avoid adding manual settings unless you actually need them. A manual configuration that fixes something today can become confusing later if the company changes its proxy configuration.

The awkward part of corporate proxies is rarely the proxy itself. It is that every developer tool has slightly different ideas about where proxy settings should live and which settings it respects.

Once you know the proxy hostname, port, and bypass list, the remaining job is usually just working through those tools one by one.

How to diagnose the problem

When something cannot reach something else, work through these in order. It takes two minutes and saves hours.

First, is it name resolution?

nslookup registry.npmjs.org

nslookup checks whether your machine can resolve the hostname itself. That process is called name resolution. This is especially important for hosts you expect to reach directly. If it fails, DNS is one possible cause, although a proxy may resolve public hostnames on your behalf. On a VPN this is a common cause, because connecting can change which DNS servers you use.

Second, does it reach at all?

curl -v https://registry.npmjs.org

curl makes an actual network request. The -v flag means verbose, so it prints the connection steps: whether it is using a proxy, whether it connected, and where it failed.

Third, compare with and without.

curl -v --noproxy '*' https://internal-service.example.internal

This command forces a direct connection and bypasses any proxy settings. If the direct attempt works and the normal one does not, your bypass list is the problem. If the reverse is true, your proxy configuration is.

Fourth, check what the tool actually sees. A tool launched from your desktop environment does not necessarily inherit environment variables you set in your shell profile. This is a common cause of "it works in the terminal but not in the IDE". If your IDE is launched by the desktop rather than from a shell, it may see none of your exports. In practice, that means the terminal may know about HTTP_PROXY and NO_PROXY, while the IDE does not. Some IDEs let you define environment variables for terminals, run configurations, or extensions, but often the simpler fix is to use the IDE's own proxy settings screen if it has one.

Take away actions

Next in the series: you have reached the proxy, and now everything fails with a certificate error. Here is why, and how to fix it properly rather than by turning verification off.