Fix GitHub Copilot CLI Not Working With v2rayN Proxy

When GitHub Copilot CLI cannot authenticate, hangs during startup, or repeatedly reports a network timeout behind v2rayN, the node is not automatically the problem. The terminal application may be bypassing v2rayN even while browsers work normally. A browser can use the Windows system proxy, while a command-line process may read only environment variables, use its own HTTP client, or connect directly through the operating system network stack.

The complete path contains several independent layers: v2rayN must be running, the Xray core must have an active outbound, a local HTTP or SOCKS listener must be available, the terminal must know that listener, routing rules must send the required GitHub domains to the intended outbound, and DNS must resolve those domains successfully. Authentication adds another layer because the CLI may open a browser, request a device code, contact an API endpoint, and then exchange credentials over several HTTPS connections. Testing only one website in a browser does not validate this entire chain.

Map the connection path before changing the node

Start by deciding which traffic path the CLI is supposed to use. In the ordinary system-proxy design, v2rayN starts the Xray core, the core opens local listeners, and Windows applications that honor the system proxy send web traffic to the local HTTP proxy. The terminal then needs to inherit equivalent proxy settings. A simplified path is:

On many v2rayN installations, the local HTTP proxy is 127.0.0.1:10809 and the local SOCKS proxy is 127.0.0.1:10808. These are common examples, not universal defaults. Check the actual values in the v2rayN settings and use those values in every command. A port mismatch is one of the fastest ways to produce a misleading “connection refused” or timeout message.

Use the HTTP listener for the first diagnostic because many command-line libraries recognize HTTP_PROXY, HTTPS_PROXY, and NO_PROXY more consistently than they recognize SOCKS settings. A URL beginning with https:// still commonly uses an HTTP proxy through the CONNECT method; the proxy itself does not need to be an HTTPS server. If you choose SOCKS, verify that the application supports socks5h:// rather than assuming that socks5:// will resolve DNS remotely.

Set and verify proxy variables in the terminal

On Windows, environment variables are attached to a process when that process starts. If you add a variable after opening PowerShell, the existing window may not see it. Close and reopen the terminal after changing persistent settings, and restart the editor or terminal host if Copilot CLI is launched from an integrated terminal. Variable names are commonly treated case-insensitively on Windows, but setting both uppercase and lowercase forms avoids surprises when a tool or runtime checks a specific spelling.

For a temporary PowerShell test, replace 10809 with the HTTP port shown by v2rayN:

$env:HTTP_PROXY  = "http://127.0.0.1:10809"
$env:HTTPS_PROXY = "http://127.0.0.1:10809"
$env:ALL_PROXY   = "http://127.0.0.1:10809"
$env:NO_PROXY    = "localhost,127.0.0.1"

$env:http_proxy  = $env:HTTP_PROXY
$env:https_proxy = $env:HTTPS_PROXY
$env:all_proxy   = $env:ALL_PROXY
$env:no_proxy    = $env:NO_PROXY

Get-ChildItem Env:*proxy*

For Command Prompt, use the equivalent session-level commands:

set HTTP_PROXY=http://127.0.0.1:10809
set HTTPS_PROXY=http://127.0.0.1:10809
set ALL_PROXY=http://127.0.0.1:10809
set NO_PROXY=localhost,127.0.0.1

set http_proxy=%HTTP_PROXY%
set https_proxy=%HTTPS_PROXY%
set all_proxy=%ALL_PROXY%
set no_proxy=%NO_PROXY%

Do not put the GitHub domains in NO_PROXY. An entry such as NO_PROXY=github.com,api.github.com deliberately bypasses v2rayN for those destinations and can recreate the timeout. Keep NO_PROXY limited to local addresses and services that must never leave the computer. Also inspect inherited variables before testing: a stale corporate proxy, a port from another VPN client, or a malformed value containing an extra quote can override the intended route.

Use curl to test the local proxy independently of Copilot CLI. The following request checks whether the local HTTP listener can create an HTTPS connection to a GitHub API host:

curl.exe -v --proxy http://127.0.0.1:10809 https://api.github.com/

A successful response may be an HTTP 200 response containing API metadata, or another valid HTTP response from the remote service. An authentication-related 401 is still evidence that the HTTPS request reached the API; it is not the same as a local proxy refusal. In verbose output, look for a connection to 127.0.0.1:10809, an HTTP CONNECT request, a successful tunnel response, and a completed TLS handshake. If the command cannot connect to the local address, fix v2rayN or the port first. If the tunnel opens but the request fails later, inspect routing, DNS, TLS interception, or the remote service.

Test the SOCKS listener separately only when you intend to use it:

curl.exe -v --proxy socks5h://127.0.0.1:10808 https://api.github.com/

The h in socks5h asks the proxy to resolve the destination name. This matters when local DNS is polluted, unavailable, or routed differently from the proxy path. If the SOCKS test works but the CLI still fails, the CLI may not read ALL_PROXY, may support only HTTP proxies, or may launch a child process with a cleaned environment. Prefer the HTTP listener for compatibility, then consult the CLI’s own proxy option or runtime documentation.

1. Check the listener: In v2rayN, verify that the core is running and that the configured HTTP port is listening on 127.0.0.1.
2. Check inheritance: Run Get-ChildItem Env:*proxy* in the same terminal that launches the CLI.
3. Check HTTPS: Run the verbose curl.exe request through the exact port used by the variables.
4. Check authentication: Start the CLI login flow again from that same terminal rather than from a different shell.
5. Check persistence: If the temporary test succeeds, configure the variables persistently and open a new terminal window.

Check v2rayN routing, DNS, and TUN mode

Once the local listener accepts traffic, determine whether the request is leaving through the expected outbound. v2rayN may be in rule mode, global mode, or a custom routing mode. In rule mode, GitHub-related domains can be sent direct while other traffic uses the proxy. That may work on one network and fail on another. For diagnosis, use a known-working routing profile or temporarily select global proxy mode, then repeat the same curl request. If global mode works but rule mode fails, the node is probably usable and the problem is in routing or domain matching.

GitHub authentication is not always one request to one hostname. The initial login, token exchange, API calls, and Copilot service requests can involve different hostnames and redirects. A rule that covers only github.com may not cover api.github.com or the service hostname used by the installed CLI version. Inspect the Xray access log while starting authentication and note the destination names and the selected outbound. Do not blindly add every unfamiliar hostname to a permanent rule; confirm that it belongs to the login or Copilot flow and keep the rule set narrow enough to maintain.

DNS creates a separate failure boundary. A browser may resolve a domain through the system proxy or its own secure DNS implementation, while the terminal and Xray core may use different resolvers. In v2rayN, check the DNS section of the active configuration and determine whether domain queries are handled locally, sent to a remote resolver, or captured by TUN mode. If the access log shows an IP address but no usable domain, domain-based routing may not match as expected. If the log shows repeated DNS failures before any outbound connection, changing the Copilot token will not help.

TUN mode can solve applications that do not honor HTTP or SOCKS environment variables. It creates a virtual network interface and captures traffic at the operating-system network layer, allowing more applications to enter the Xray routing path without explicit proxy configuration. However, TUN is not a universal repair. It can introduce default-route conflicts, DNS interception loops, permission problems, and clashes with another VPN or virtual adapter. Enable it only after ordinary local-proxy testing has established a baseline.

When testing TUN, close duplicate proxy applications, disable other VPN adapters temporarily, and confirm that v2rayN has the required administrator permission if the platform requests it. Check whether the CLI process was started before TUN was enabled and restart it when necessary. If TUN captures the CLI but the request loops indefinitely, inspect whether the TUN interface’s own DNS or control traffic is being sent back into the same capture rule. Local addresses, the v2rayN API or control port, and private LAN ranges should normally remain direct.

Repeat authentication only after network validation

Authentication errors are easy to misread because an unavailable network can appear as an invalid login. First confirm that a proxied HTTPS request completes, then run the CLI’s supported login or authentication command from the same shell. If the flow opens a browser, keep the original terminal open and complete the browser step without clearing the terminal’s environment. The browser and CLI may use different proxy paths, so successful browser authorization alone does not prove that the token exchange in the terminal can complete.

Check the account and credential layer separately. A token may be expired, revoked, missing required access, associated with a different account, or stored in a credential manager that the current user cannot read. Do not paste access tokens into logs, screenshots, shell history, or support requests. If the CLI offers a logout or credential reset command, use that supported mechanism, then authenticate again after the proxy test passes. Avoid deleting unrelated credential files or changing account settings merely because the first request timed out.

Command-line tools can also be started by an editor, task runner, service wrapper, or another shell. These launchers may not inherit the variables set in an interactive PowerShell window. Compare the environment from the exact execution context: an integrated terminal, a standalone terminal, and a background task are separate test cases. If the command works interactively but fails from an editor task, configure the task’s environment or use TUN mode for that process rather than changing the v2rayN node.

The final verification should be repeatable. Start v2rayN with the intended core and active server, confirm the local HTTP port, open a new terminal, print the proxy variables, run the proxied API test, and then launch the Copilot CLI authentication or request command. Watch the v2rayN access and error logs during the operation. A working result should show a connection arriving at the local listener, a domain resolved through the chosen DNS path, an outbound selected according to the routing rule, and no repeated local connection refusal or TLS timeout.

If the proxied curl test fails in both rule and global modes, investigate the Xray core, node parameters, remote port, system time, and transport settings. If curl succeeds but Copilot CLI fails, focus on environment inheritance, supported proxy schemes, credentials, and the process that launched the CLI. If only TUN succeeds, treat that as evidence that the application bypasses explicit proxy variables—not as proof that the node is defective. Keeping these conclusions separate prevents unnecessary subscription edits and makes future troubleshooting much faster.