Document proxy support

Describe the feature or problem you’d like to solve

Right now it's impossible to use GitHub CLI behind a proxy. Even if you have a proxy set up in the OS or in git GitHub CLI it doesn't work

Note: I'm using Windows 10

Proposed solution

Allow to configure the use of a proxy (maybe the same as git). Something like:

gh config set http_proxy https://user:password@host:port
gh config set https_proxy https://user:password@host:port

@YasielCabrera

@YasielCabrera Can you try setting the https_proxy environment variable? In Powershell, that would be:

$env:https_proxy = "https://user:password@host:port"

But I agree that we should probably support a configuration option for a proxy. Not sure why Go is not picking up or respecting the OS-wide proxy setting.

@mislav

@mislav using environment variables in Powershell it works perfectly, thanks

Note: using env vars seems not to work in the CMD

Is connecting through unix sockets supported? i.e. with curl it would be curl --unix-socket $HOME/.proxy https://github.com.

Yes Indeed

Same problem here running Windows 10.

When the once I got gh auth login to work (nowhere does it say you need to do this from an elevated prompt)...

Without setting the proxy env variable results in "wsarecv: An existing connection was forcibly closed by the remote host." i.e. gh has no notion of the proxy being present.
Setting the proxy env variable in cmd does nothing
Setting the proxy env variable powershell desktop (5.1) results in "proxyconnect tcp: EOF"
Setting the proxy env variable powershell core (7.1.3) results in "proxyconnect tcp: net/http: TLS handshake timeout"

I can get to https://api.github.com/graphql using my browser (I get the API rate limit warning since I am not authenticated) and from a REST client (authenticated) from the same system so the problem is definitely in gh not understanding how to recognize and use a proxy configured at the OS level.

I would also add that tagging this as an enhancement is not correct this is a bug. If you software needs to traverse a network and it can't handle an proxy then it's not ready for production release, at least not for business use. I challenge you to show me a security conscious company today who it not running a either host or network based proxy.

@mislav

@mislav way works, but in my case I did small adjustment described in docker/for-linux#415 - I set proxy URL's protocol to http instead of https

$Env:https_proxy = "http://proxy.example.com:port"

Given that Go supports the HTTP_PROXY and NO_PROXY environment variables, I think the best we can do is document those variables better in our manual; going to rename this issue to reflect that.

I just tried this from bash (in Windows 10), and it does not seem to work. It works as expected with curl, but not gh.

This command is sent to my proxy server:

HTTP_PROXY="http://localhost:8888" curl -s github.com

This command isn't sent to my proxy server:

HTTP_PROXY="http://localhost:8888" gh repo view

@v3gard

@v3gard GitHub CLI mostly makes HTTPS requests (unless to a GitHub Enterprise instance that has been explicitly configured for HTTP). To make gh traffic go through a proxy, use HTTPS_PROXY, not HTTP_PROXY.

@mislav

To make gh traffic go through a proxy, use HTTPS_PROXY, not HTTP_PROXY.

Thanks @mislav. That did it. One interesting thing to note though.

As mentioned earlier, this doesn't work:

HTTP_PROXY="http://localhost:8888" gh repo view

But this works! Note that [1] we're using HTTPS_PROXY and [2] we're going through the same proxy server as before (that responds to http and not https).

HTTPS_PROXY="http://localhost:8888" gh repo view

@v3gard

@v3gard Yeah, the "https" in HTTPS_PROXY refers to the fact that HTTPS requests will be proxied, not to the protocol where the proxy server itself listens on.

This was the reason I was getting

> gh auth login -w

failed to authenticate via web browser: Post "https://github.com/login/device/code":
dial tcp xxx.xx.xxx.x:xxx: connectex: A connection attempt failed because the connected party
did not properly respond after a period of time, or established connection failed because
connected host has failed to respond.

(Pasting error message so other people can find the solution above more easily)

If you are using PowerShell you can try like this: [net.webrequest]::DefaultWebProxy = new-object net.webproxy "http://127.0.0.1:10801"

Adding another perspective here: I think it would still be valuable for the GitHub CLI to support a proxy configuration of its own, for ecosystems that require more fine-grained network control. Relying on the "standard" proxy variables means that any other processes launched by the shell running the CLI will also receive that proxy config, which might be undesirable. NO_PROXY helps, but is less robust if the goal is ultimately to only use a proxy for GitHub.

Adding another perspective here: I think it would still be valuable for the GitHub CLI to support a proxy configuration of its own, for ecosystems that require more fine-grained network control.

For areas where direct access to GitHub is restricted or unstable, it is usually necessary to try several different proxy software simultaneously. Currently, I have tried modifying the proxy using the following method, but it did not work.

C:\Git_Playground\myproject>gh config set http_proxy http://localhost:12345
! warning: 'http_proxy' is not a known configuration key

I learned about http_proxy from #8623 because I also encountered a similar problem when trying to log in (consistent with #8623).

failed to authenticate via web browser: Post "https://github.com/login/device/code": dial tcp 20.205.243.166:443: connectex: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

The system I am using is Windows 11 26020.rs_prerelease.231214-1452, and I have not tried it on other operating systems yet.

since now github only support gh and ssh.
http/https is useless now.
So gh socks5 proxy support is needed!

Here’s how to solve the problem elegantly and once and for all:

# bash
alias gh="HTTPS_PROXY='http://localhost:7890' gh"

# pwsh
function gh_proxy {
    $originalProxy = $env:HTTPS_PROXY
    $env:HTTPS_PROXY = 'http://localhost:7890'
    
    try {
        gh.exe @Args
    } finally {
        $env:HTTPS_PROXY = $originalProxy
    }
}

Set-Alias gh gh_proxy

I need to use SOCKS5 proxy and I did not find a way how to do that.
There is also #6689 , but it was closed without an answer.

The gh cli does not gracefully degrade when a proxy should be used, eg. in my corporate environment:

gh ext install github/gh-stack
✓ Installed extension github/gh-stack

But the HTTPS request got aborted somewhere with a RST_STREAM resulting in an empty file and thus an unusable extension without the user (me) knowing what caused it

Additional reproduction on Windows with GitHub CLI 2.101.0:

Direct gh auth login failed at the device-code request with Post "https://github.com/login/device/code": EOF.
The local proxy was Mihomo/Verge on 127.0.0.1:7897, exposing SOCKS5.
Using HTTPS_PROXY=socks5://127.0.0.1:7897 allowed the device flow to complete and the CLI stored credentials successfully.
socks5h://127.0.0.1:7897 was not reliable in the same setup and could fail at the device-code request.
Clearing stale GH_TOKEN/GITHUB_TOKEN variables was also necessary; otherwise gh auth login refused to store credentials and used the environment token instead.

This suggests the documentation should explicitly distinguish HTTPS_PROXY (the proxy for HTTPS requests) from HTTP_PROXY, document SOCKS5 usage on Windows, and explain that stale token environment variables override interactive login. A short troubleshooting section or a first-class proxy setting would make this failure much easier to diagnose.

Navigation Menu

Repository navigation

Document proxy support #2037

Describe the feature or problem you’d like to solve

Proposed solution

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Document proxy support #2037

Description

Describe the feature or problem you’d like to solve

Proposed solution

Activity

mislav commented on Oct 1, 2020

YasielCabrera commented on Oct 1, 2020

qaisjp commented on Nov 11, 2020

Oshimarr36 commented on Mar 20, 2021

RobertKlohr commented on Mar 29, 2021

ababushk commented on Sep 10, 2021

vilmibm commented on Mar 2, 2022

v3gard commented on Oct 6, 2022

mislav commented on Oct 6, 2022

v3gard commented on Oct 6, 2022

mislav commented on Oct 7, 2022

MetRonnie commented on Nov 8, 2022

zaevi commented on Dec 5, 2022

nmck257 commented on Jan 18, 2024

LaoshuBaby commented on Jan 28, 2024

calidion commented on Nov 17, 2024

nmnmcc commented on Dec 28, 2024

tprochazka commented on Oct 7, 2025

janv8000 commented on May 4, 2026

2667741708 commented on Sep 21, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions