GitHub Proxy: Cloning, Asset Traffic and Device Synchronisation
The difficult part of configuring a proxy for GitHub is that a single setting does not cover three different traffic families at once: the browser interface, the git client on the command line and the interface your scripts talk to all take separate paths. This page covers all three separately.
Three traffic familiesThe separate scopes of the web interface, the git protocol and automation requests.
02
Git configurationThe client setting on the HTTPS side, the tunnel approach on the SSH side.
03
Leak checkWhat DNS and WebRTC leaks reveal in developer use.
04
Multiple devicesConcurrent sessions and per-device credential separation.
When working with GitHub the browser is only the surface. The git client that clones the repository is a separate process, the continuous integration runner is a third machine, and the interface your script calls uses a fourth path. Defining a proxy in the browser does not automatically affect any of them.
The second source of complexity is that raw file content, release assets and user images are served not from the main domain but from separate hosts. This separation is deliberate and necessary for caching and distribution; however, it is the first thing to break when you write a narrowly scoped proxy rule.
The sections below unpack these distinctions one by one, then move on to what stays visible inside the tunnel and what to watch out for when using multiple devices.
GitHub traffic does not fit a single pattern
At the top is the browser layer: repository pages, review screens, settings and search. This layer behaves like an ordinary web session, carries cookies and obeys the browser profile's proxy rule. A setting made here does not affect git commands on the same machine.
In the middle sits the git protocol. clone, fetch and push commands run either over HTTPS on port 443 or over SSH. Two transports mean two separate configurations: on the HTTPS side the client's own proxy setting comes into play, while on the SSH side the connection has to be routed through a tunnel.
At the bottom are scripts and automation. These requests are authenticated with a token and usually go through a library. Most libraries read environment variables; some do not and expect their own configuration. Rather than assuming whether a script uses the proxy, you need to test it.
Do not set anything up before deciding which of these three layers you want to route. If you only want to verify the regional view, the browser layer is enough; if continuous integration jobs need to exit from a fixed address, the real work is in the bottom layer.
DIAGRAMThe three traffic families in GitHub use
You can scroll the diagram horizontally to inspect it
Each layer reads its own configuration. A setting made in the browser does not cover git commands, and a git setting does not cover scripts; coverage has to be built layer by layer.
Cloning goes through two transports: HTTPS and SSH
When cloning over HTTPS, the git client behaves like an ordinary HTTP client. You can write the proxy into the client's own configuration; the http.proxy key is used for this, and git applies this value to HTTPS remotes as well. If you want to write a rule for a specific address only, you can use the http.<url>.proxy form. If you write repository-specific configuration, the rule applies only to that working copy, which is the cleanest way to route different projects through different exits.
On the SSH side the situation is different. SSH has no concept of an HTTP proxy of its own; the connection has to be tunnelled through a helper program or carried over SOCKS. In the client configuration you define a host-specific rule and route the connection through this tunnel. If port 22 is closed on corporate networks, directing SSH to the alternative endpoint that speaks over 443 is a common solution.
Which transport you choose depends largely on your environment. HTTPS creates less friction on restricted networks because it is compatible with proxies and can pass through tight firewalls. SSH, working with key-based identity, is preferred by teams that do not distribute passwords.
Using the two transports side by side is also possible in mixed environments: you can define most repositories over HTTPS and switch to a key-based connection for a single project. When you change the address format, the authentication method changes too; when moving from a token-based setup to a key, the permission scope needs reviewing. If you use more than one identity on a single machine, state explicitly in the client configuration which project talks with which identity.
If you want to set up a SOCKS-based tunnel, the article on SOCKS5 tunnels over SSH shows the steps; the SOCKS5 proxy page explains why the protocol suits this job, and the HTTP proxy page explains the difference on the HTTP side.
Raw files and release assets are separated from the main domain
When you view a file's raw content, download an archive from a release page or load a user image, the request goes not to the main domain but to a separate user content host. Downloading repository archives similarly lands on a different endpoint. This separation allows large files to be distributed over a cacheable path.
From the proxy's point of view the consequence is clear: if you have written a rule that targets only the main domain, the page opens but the raw file and download requests fall outside the rule and go directly. This produces misleading results during regional verification; the interface appears to come from the country you expect while the download traffic flows from your real address.
The same applies to the large file storage extension. Object contents are pulled from a separate endpoint and the client opens a second connection to that address. When writing rules, taking a broad approach instead of a domain list is more robust than chasing endpoints one by one.
Do not verify by eye: after starting a download, look at the connection log on the proxy side or with the proxy checker tool test that the exit is genuinely being used. If you are going to download at scale, the bandwidth calculation article helps you plan the cost side.
DIAGRAMHow strongly each configuration point covers each traffic type
You can scroll the diagram horizontally to inspect it
Cell values are not measurements but the weight with which that configuration point covers the relevant traffic. Dark cells show where that setting is decisive, light cells where it has no effect. SSH traffic is not routed by environment variables; it is carried only by a host-specific tunnel rule.
Choose the right exit for your development environment
A fixed address for runners and scripts, and location variety for regional verification, correspond to different products.
Choose whichever you need from our residential proxies, datacenter proxies, IPv6 and ISP solutions. Every plan comes with unlimited options, 99.9% uptime, rotating proxies, sticky sessions and 24/7 support. Ideal for web scraping, ad verification, SEO monitoring and digital data collection.
ISP ProxyStatic Turkish IPs registered to an ISP
ISP-registered static Türkiye IPs; they combine datacenter speed with the reputation of a real carrier. Ideal for long sessions and low-ping use.
What do DNS and WebRTC leaks reveal on the developer side?
Defining a proxy does not mean domain resolution also goes through the proxy. If the client resolves the domain with the local resolver and only hands the connection to the proxy, which hosts you are going to is visible to your network provider. On the developer side this is more than an ordinary privacy issue: the subdomain of an in-house GitHub instance often carries the company name, and the resolution record exposes that name.
Even on encrypted connections the domain name can be carried during the handshake in the server name indication. The content cannot be read, but where you are connecting can be visible to an observer on the path. That is why, when choosing a proxy, where resolution happens matters at least as much as the exit address itself. With SOCKS5 you can configure whether resolution is done on the client or at the remote end; the detail is where DNS is resolved in SOCKS5 the article.
The second risk on the browser side is the WebRTC interface. Through this interface a page can learn your real local and public addresses. If the proxy only routes HTTP traffic, this channel stays open and the exit appearance you carefully built becomes meaningless with a single query.
Repeat these tests not only on the day of setup but whenever something changes on the network side. An operating system update, a new browser profile or newly installed security software can silently change the resolver preference, and coverage that was set up correctly months ago can open up without your noticing.
What is visible inside the tunnel and what is not?
When an encrypted connection is requested, the client first sends the proxy a request to open a tunnel. The target host and port are written plainly in that request; this is where the proxy learns where to connect. If authentication is required, the username and password are carried in a separate header.
Once the tunnel is established, the encrypted handshake between client and server begins. At this stage the server name indication is still visible; everything that flows after that is a meaningless sequence of bytes to the proxy. The repository name, file contents, commit messages and access token cannot be read by the proxy.
This distinction cuts both ways. On one hand your provider cannot see your code; on the other, which hosts you connect to and how often can be logged. That is exactly what makes choosing a provider a matter of trust.
Embedding access credentials in the address line is a common but risky habit; shell history, script files and error output keep that line as it is. Holding credentials in a separate configuration file or an environment variable prevents an accidentally shared log file from exposing your exit to third parties.
Tip
Keep your access tokens separate from your proxy credentials and do not store the two in the same file. The protocol side of the tunnel approach is covered the HTTP CONNECT method, and how certificate validation works is covered TLS certificate validation article.
DIAGRAMThe field structure of a tunnel request
You can scroll the diagram horizontally to inspect it
The first two fields are read by the proxy; in the third field only the server name can be seen. Everything after the fourth field is a meaningless sequence of bytes to the proxy.
Multi-device and concurrent session behaviour
Using the same account from a laptop, a desktop, a phone and a runner on a server at the same time is normal. The platform expects this concurrency; each device carries its own credentials. The browser uses a session cookie, the git client a token or a key, and the runner a separate identity.
When a proxy comes into play, the point to note is that all devices do not have to be forced onto the same exit. On the contrary, it is healthier for each device to have a coverage suited to its own context: a developer machine may use one exit for regional verification while the runner exits from a fixed address recognised by the organisation.
Device or process
Identity carried
Where proxy coverage comes from
Desktop browser
Session cookie
Browser profile or system setting
Command-line git (HTTPS)
Personal access token
The client's own configuration
Command-line git (SSH)
Public key
Host-specific tunnel rule
Continuous integration runner
Job token
Environment variables
Mobile app
Device session
Only the wireless network you are connected to
Remember that the number of concurrent connections also has a limit on the proxy side; a runner cloning in parallel opens several connections on its own. How the limits are calculated is concurrent connection limit is explained in that article.
Are request limits tied to the address or to the token?
The critical distinction in programmatic access is this: unauthenticated requests are generally counted against the address the request comes from, while authenticated requests are counted against the token used. This distinction also determines what you should expect from a proxy.
In a script authenticated with a token, changing the exit address does not reset the counter; the limit is written against the token. So the expectation "if I turn on rotation I can send more requests" is an assumption with no basis in this scenario. The right approach is to reduce requests, cache results and honour the wait directives the server returns.
The places where an address-based limit is meaningful are different: many developers working from a shared office exit all consume the same counter if they are all sending unauthenticated requests. In such a case, giving the team a separate exit or authenticating the requests solves the problem at source.
The general framework for automation on the proxy side is covered on the proxy for automation and bots page, while how to manage an address pool is covered in the proxy pool article. In both cases, complying with the platform's terms of use is a basic requirement.
When is a proxy needed, and when is it just an extra layer?
If you work from your own country, on your own connection, with a single account, putting a proxy in between gains you nothing; it only adds a point of failure and a little latency. In that case leaving the configuration as it is is the best decision.
The situations where a proxy becomes meaningful are generally these: speaking from a fixed, recognised exit on corporate networks where access is restricted to specific addresses, verifying how a documentation site distributed from different regions looks, separating test environment traffic from production traffic, and using a single auditable gateway when exiting a restricted network.
Take cost into account when deciding, too. Cloning and archive downloads are high-volume tasks; assuming unlimited use without measuring ends in surprises. What to test during a trial is listed in the how to test a trial version article.
Another criterion is team size. In a one-person setup the configuration is easy to remember; in a ten-person team it is unrealistic to assume that the same setting is correctly in place on everyone's machine. At this point, moving coverage away from personal machines and onto shared runners and shared environments is a far more robust solution.
If you want to see how the same questions play out in a different ecosystem, the GitLab proxy page goes into more detail on the continuous integration and object storage side.
Frequently asked questions about GitHub proxies
01I defined a proxy in the browser — why are git commands unaffected?
The git client is a process independent of the browser and reads its own configuration. If you work over HTTPS you need to set the client's proxy keys; if you use SSH you need to route the connection with a host-specific tunnel rule.
02The page opens but the raw file will not download — what could be the reason?
Raw file content and release assets are served not from the main domain but from a separate user content host. If your rule only targets the main domain, these requests fall outside its scope. Writing a broader rule or using a system-wide setting solves the problem.
03Is it possible to route an SSH connection through a proxy?
Yes, but not with an HTTP proxy setting. The connection has to be tunnelled through a helper program or carried over SOCKS. If port 22 is closed on a corporate network, directing SSH to the alternative endpoint that speaks over 443 is a common method.
04Can the proxy provider see the contents of the repository?
Not over an encrypted connection. Once the tunnel is established, the bytes flowing through it are meaningless to the proxy; the repository name, file contents and tokens cannot be read. However, which host you connect to and how often can be visible on the proxy side.
05Can I raise my request limit by changing address?
Not for authenticated requests: the limit is tied to the token, and changing the exit address does not affect the counter. For unauthenticated requests the counter may be tied to the address; in that case the right solution is to authenticate the requests and cache the results.
06Why do DNS leaks matter for developer use?
Resolution records show which hosts you connect to. Because the subdomain of an in-house instance often carries the company name, the context can be exposed even if the exit address is hidden. Always run a DNS leak test after setup.
07Does every device have to use the same exit?
No, and most of the time it is not necessary. A developer machine may use one exit for regional verification while the continuous integration runner exits from a fixed address recognised by the organisation. What matters is that each device's coverage is chosen deliberately.