In this Article
Working with GitHub from inside a corporate network is usually a configuration problem spread across five tools that do not share settings. A clone works and npm install fails; npm works and Docker cannot pull; everything works on the command line and the IDE cannot reach anything.
This guide covers where each tool reads its proxy settings, why SSH behaves differently from HTTPS, how to read the four error types you will actually see, and the two shortcuts that are worth refusing.
Key Facts
- Each tool has its own proxy configuration. Git, npm, pip, Docker and your shell all read different settings, which is why fixing one leaves the others broken.
- SSH usually fails where HTTPS works, because most corporate proxies forward only HTTP CONNECT on standard ports.
- Certificate errors almost always mean TLS inspection, and the fix is trusting the corporate CA rather than disabling verification.
- Never disable certificate verification to make a clone work. It turns a visible configuration problem into an invisible security one.
- Credentials in a proxy URL leak into logs and shell history, so use the tool’s credential store instead.
Where does each tool read proxy settings?
Separately, which is the root of most of the confusion. We call it the 4-part toolchain model.
| Tool | Where it looks | Common gap |
|---|---|---|
| 1. Git | Its own config, then environment variables | HTTPS remotes work while SSH remotes do not |
| 2. Package managers | Their own config files, then environment variables | Each one needs configuring separately; registries may differ from GitHub |
| 3. Docker | Daemon configuration, not just your shell | Shell variables do not reach the daemon that pulls images |
| 4. IDEs and editors | Their own settings, sometimes the system store | Terminal works, integrated features do not |
A working github proxy setup therefore means five configurations, not one. The practical order is to set environment variables for the shell, then configure git, then each package manager, then the Docker daemon, and to include a no-proxy list for internal hosts from the start. Skipping the last step is what makes internal services unreachable after an otherwise successful setup.
Why does SSH fail when HTTPS works?
Because they are different protocols on different ports, and most corporate proxies forward only HTTP CONNECT to a small set of ports.
Git over HTTPS is an ordinary web request that a proxy handles natively. Git over SSH uses port 22, which is usually not permitted through the proxy at all. The result is that a repository clones fine with an HTTPS remote and times out with an SSH remote, and the error message rarely says why.
Three practical resolutions, in order of preference: switch the remote to HTTPS with a token, use SSH over the HTTPS port where GitHub supports it, or ask the network team to permit SSH to specific hosts. The first works everywhere and is what most teams settle on.
How do you read the errors?
| Error | Use this fix when | Avoid when |
|---|---|---|
| Certificate verification failed | Add the corporate CA to the tool’s trust store | Never disable verification, which hides a real risk |
| Connection timed out on an SSH remote | Switch to HTTPS or SSH over the HTTPS port | Retrying; the port is blocked, not slow |
| Proxy authentication required | Configure credentials in the tool’s store | Putting them in a URL, which leaks to logs |
| Works in terminal, fails in Docker | Configure the Docker daemon, then restart it | Adding more shell variables, which the daemon never reads |
| Internal hosts unreachable after setup | Add them to the no-proxy list | Removing the proxy config entirely |
The first row is the one worth being firm about. TLS inspection means a middlebox is terminating and re-signing your connections, and the correct response is to trust the organisation’s CA deliberately. Disabling verification makes the error disappear and makes every future interception invisible.
When is an external proxy the right tool?
Rarely for this problem, and it is worth being clear about that.
A corporate proxy is infrastructure your organisation runs, and the fix for GitHub access behind it is configuration, not a second proxy. Routing around a network control your employer deliberately put in place is a policy question before it is a technical one.
Where a commercial proxy genuinely applies is different work that happens to involve GitHub: collecting public repository data at scale, checking how a public page renders from another country, or running automated checks from multiple regions. For collecting repository data specifically, the GitHub API with a token is the right answer first, and it is generous enough that scraping is rarely justified.
When collection does need distributed exits, DataImpulse residential covers 195 countries at $1 per GB. Related: proxies for web scraping, 403 Forbidden explained.
Frequently Asked Questions
How do I configure git to use a proxy?
Set the proxy in git’s own configuration or in the standard environment variables, and add internal hosts to a no-proxy list at the same time. Git reads its own config separately from npm, pip and Docker, so each tool needs configuring individually.
Why does git clone over SSH fail behind a proxy?
Because SSH uses port 22 and most corporate proxies forward only HTTP CONNECT to standard web ports. HTTPS remotes work because they are ordinary web requests. Switching the remote to HTTPS with a token is the resolution that works in the most environments.
What causes certificate errors behind a corporate proxy?
TLS inspection: a middlebox terminates and re-signs your connections with the organisation’s own certificate authority. The fix is to add that CA to each tool’s trust store. Disabling certificate verification removes the error and removes your ability to detect real interception.
Why does Docker fail when my terminal works?
Because the Docker daemon pulls images, not your shell, and it reads its own configuration rather than your environment variables. Configure the daemon’s proxy settings and restart it.
Should I use a commercial proxy to reach GitHub at work?
No. A corporate proxy is infrastructure your organisation runs deliberately, and the fix is configuration. Commercial proxies apply to different work, such as collecting public data from many regions, and even there the GitHub API with a token is usually the better route.
When the work is collection, not connectivity
Checking how public pages render from other regions, or collecting public data at scale, is a different problem from corporate network configuration. DataImpulse residential proxies cover 195 countries at $1 per GB. Create an account when that is the job.
Related: proxies for web scraping · 403 Forbidden when scraping · what is a web proxy.
Last updated: September 17, 2026.
State/City/Zip/ASN Targeting 
