Slow GitHub clones, Docker image pulls, npm installs, and API tests can look like one network problem, but they often fail at different layers. A command-line tool may not use the same proxy as your browser; Docker’s daemon can have separate network settings from a container; and a package registry can be slow even when ordinary websites load normally. The useful first step is to identify which request is delayed, then change the smallest relevant setting.
This guide covers practical checks for local development and CI. It focuses on reproducible configuration rather than a particular speed claim: network performance depends on your location, connection, destination, routing, and the state of the service you are contacting. Keep a record of the original configuration before changing proxy or registry settings so you can restore it if another tool stops working.
Identify the bottleneck before changing settings
Separate the workflow into the request that is failing. A Git clone contacts a Git host; an npm install contacts a package registry and may also retrieve packages from URLs recorded in lockfiles; a Docker pull contacts a registry and possibly redirects to image storage; a build can then download additional files from inside a build container. An API test has its own destination, authentication, DNS lookup, and proxy behavior. Improving one path does not automatically improve the others.
Start by reproducing the issue with one small operation. Note whether it is a timeout, a name-resolution error, a connection reset, an authentication failure, or a slow transfer that eventually completes. These symptoms point to different causes. A DNS error usually calls for checking name resolution or the network’s DNS path. A TLS certificate error is not a reason to turn off certificate verification. A 401 or 403 response is generally about credentials or permissions rather than bandwidth. A connection timeout may involve a firewall, proxy, route, or unavailable endpoint.
Check the same destination from the same machine and network before and after a change. Avoid running several downloads at once while testing: parallel traffic can make results hard to interpret and can trigger rate limits. Also check whether the problem affects every project or only one repository or package. If only one project fails, inspect its lockfile, configuration files, and CI settings before changing machine-wide networking.
4
common workflow layers
3
useful test scopes: local, container, CI
The four common layers are the developer machine, the application or package manager, the container engine or build environment, and the CI runner. A practical diagnosis compares those scopes rather than assuming a single global proxy setting controls them all.
Git and GitHub: configure the client that makes the request
Git over HTTPS normally follows Git’s own configuration and the environment available to the process. A browser working through a system proxy does not prove that Git uses that proxy. Inspect the effective Git configuration and relevant environment variables before adding new settings. Be aware that a setting can come from system, global, local repository, or command-level configuration; a repository-specific value may override a global one.
For a temporary test, Git can use an HTTP proxy through a command-scoped configuration option. For a persistent configuration, choose the narrowest scope that fits your setup. A machine-wide proxy may be inappropriate on a laptop that moves between networks, while a repository-local setting can surprise another developer if it is committed or copied with the project.
# Inspect proxy settings that Git currently sees
git config --show-origin --get-regexp 'http\..*proxy'
# Test a single command with a placeholder proxy endpoint
git -c http.proxy=http://proxy.example:PORT clone https://github.com/OWNER/REPOSITORY.git
# Remove a proxy value from the global Git configuration if it is no longer needed
git config --global --unset http.proxyReplace the example endpoint with a proxy you are authorized to use. Do not put a username and password directly into a command that may be saved in shell history, process listings, logs, or CI output. If authentication is required, use an approved credential helper or your organization’s secret-management method. After testing, inspect the configuration again and remove temporary settings that should not persist.
SSH Git operations are a separate case. An HTTP proxy setting does not automatically proxy SSH connections. If your remote uses an SSH URL, check whether the network allows the SSH connection and whether your organization provides a supported SSH proxy or an HTTPS remote. Do not switch protocols blindly: repository access rules, host verification, and credential handling differ. For either protocol, keep host-key and TLS verification enabled; bypassing verification can expose credentials or source code to interception.
If only one repository is slow, inspect its remote URL and whether large files, submodules, or Git LFS are involved. A clone can appear stalled while fetching a large object or contacting a submodule host. Check the terminal output and repository configuration rather than assuming the main Git host is the only destination.
npm: check registry, lockfile, and proxy configuration
npm installs can involve more than one host. The configured registry supplies package metadata, but a lockfile may point to package tarballs at specific URLs. A registry change therefore may not reroute every download, particularly when a lockfile was created using another registry. Before changing registry settings, inspect the project’s .npmrc, the user-level configuration, environment variables, and the lockfile’s resolved URLs. Do not edit a lockfile merely to make a one-off network test pass.
Use the registry intended for the project or organization. A public mirror can be useful when it is maintained and approved for your environment, but an unknown registry can serve altered, stale, or unavailable packages. Check who operates it, whether it supports the packages your project needs, and what data it receives. Do not place private package credentials in a file that is committed to version control.
# Show npm's effective configuration
npm config get registry
npm config get proxy
npm config get https-proxy
# Inspect configuration sources and project-level settings
npm config list
# Test an approved registry for one command only
npm --registry=https://registry.example/ installThe registry URL above is a placeholder. Use the exact endpoint approved for your project; do not assume that every registry uses the same hostname or access policy. If npm is behind an HTTP proxy, configure the appropriate proxy setting for the environment and test it with a simple metadata request or a small package operation. When a setting is no longer required, remove it from the correct scope rather than layering another override on top.
Certificate errors deserve special care. Check the system clock, trusted certificate store, corporate TLS inspection policy, and any required organization-provided certificate configuration. Do not set strict-ssl=false as a shortcut. Disabling verification can make a connection appear to work while removing an important safeguard against impersonated registries and intercepted package downloads.
For repeatable builds, use the project’s existing lockfile and the package manager version expected by the project. If installation is slow only in CI, compare the runner’s registry and proxy configuration with the local environment, then review the CI cache key and cache contents. A cache can reduce repeated downloads, but a stale or incorrectly scoped cache can also create confusing failures; it does not replace checking the registry and lockfile.
Docker: distinguish daemon pulls from build-time downloads
A Docker image pull is usually initiated by the Docker daemon, not by the shell process that runs docker pull. That distinction matters: exporting a proxy variable in a terminal may help a command-line client while leaving the daemon unable to reach the registry. Docker Desktop has its own proxy controls, while a Linux Engine commonly receives daemon settings through its service configuration. Follow the method documented for your Docker installation and restart the relevant service only when required.
On a Linux host managed by systemd, an administrator may configure proxy environment variables for the Docker service using a systemd drop-in. The following is a template, not a complete configuration for every distribution. Confirm the service name, file location, and reload procedure for the host before applying it.
# Example systemd drop-in content; replace the placeholder endpoint
[Service]
Environment="HTTP_PROXY=http://proxy.example:PORT"
Environment="HTTPS_PROXY=http://proxy.example:PORT"
Environment="NO_PROXY=localhost,127.0.0.1,.internal.example"
# After changing a service drop-in, reload systemd and restart Docker
sudo systemctl daemon-reload
sudo systemctl restart dockerUse a carefully scoped NO_PROXY list for destinations that should bypass the proxy, such as local services or approved internal domains. A broad bypass entry can send traffic over an unintended route, while an incomplete list can make local development services unreachable. If a proxy requires credentials, avoid writing them into world-readable configuration or sharing them in support logs. Use your organization’s approved secret handling and file permissions.
Registry mirrors are not a universal proxy setting. A mirror may help with Docker Hub pulls if it is available, trusted, and configured for the Docker Engine you use, but it may not apply to other registries or to image layers hosted elsewhere. Do not add an arbitrary mirror simply because it appears in a blog post. Confirm that it is authorized, supports the required images, and has an appropriate trust and update policy. If only one image fails, check its registry name, tag, access permissions, and whether the image is still available.
Build-time downloads are another separate path. A build may pull a base image successfully and then fail when a package manager inside the build stage contacts its own registry. Configure the build environment deliberately and pass proxy settings using the supported BuildKit or Docker build mechanisms for your version. Do not hard-code proxy credentials into a Dockerfile with ENV or ordinary build arguments. Secrets in image layers, build logs, or cache metadata can persist beyond the current build.
When a route or proxy is part of the diagnosis, use the same destination and repeatable test rather than assuming that changing the network will solve every stage. A VPN connection can change the route used by traffic, while application-specific proxy settings can direct selected requests through a proxy; neither replaces correct registry configuration, valid credentials, or trusted TLS. For general service information, VPNText is one place to review what a VPN connection can and cannot address. Keep the test focused on the failing Git, registry, or API request, and verify that internal development services still use the intended path.
CI jobs and API tests: make environment boundaries explicit
CI runners often start with a clean environment, so a proxy configured on a developer’s laptop may not exist in the job. Check runner-level variables, repository or organization settings, container service configuration, and any job-level overrides. Confirm that the runner can resolve the destination and that its network policy allows the connection. If the job runs inside a container, distinguish the runner host’s network from the job container’s network; they may have different DNS, proxy, and certificate settings.
Keep credentials in the CI platform’s secret store, expose them only to the job that needs them, and avoid printing the full environment during troubleshooting. Masking is helpful but is not a reason to echo secrets into logs. If a token or proxy credential appears in a log, treat it as exposed and rotate it according to your organization’s process. Prefer short-lived, narrowly scoped credentials where the platform supports them.
API tests should be checked independently from Git and package downloads. Use the same method, destination, and authentication context as the test client. A proxy can affect DNS resolution and the apparent source network; a NO_PROXY rule can bypass it for selected hosts. Check whether the API returns a clear HTTP status or whether the connection fails before an HTTP response arrives. The first case may involve permissions, quotas, or application behavior; the second is more likely to involve routing, DNS, proxy, or TLS setup.
For a quick connectivity check, curl can show whether a request reaches the endpoint and whether the server returns an HTTP response. Avoid placing bearer tokens in a command that will be copied into tickets or shell history. Use a test endpoint approved by your team, and do not interpret one successful request as proof that a long-running job or large artifact transfer will perform identically.
When a VPN or proxy is enabled for diagnosis, check both the intended destination and local dependencies afterward: development databases, package mirrors, local APIs, and internal dashboards may need to bypass the external route. A clear allowlist and documented environment-specific settings are safer than disabling the VPN or proxy globally whenever a single request fails.
A safe, repeatable troubleshooting workflow
Use a small change-and-verify cycle. Save the current settings, choose one failing operation, change one variable, repeat the same operation, and record what changed. If the result is worse or unrelated, roll back before testing another hypothesis. This makes it easier to distinguish a real improvement from normal variation or a temporary service recovery.
- ✅ Identify the exact request and destination: Git host, npm registry, container registry, build dependency, or API.
- ✅ Check the configuration scope used by the process that makes the request; a browser, Git, Docker daemon, and CI container may differ.
- ✅ Use an approved proxy or registry, and keep certificate and host verification enabled.
- ✅ Store credentials in a credential helper or secret manager, not in committed files, Docker layers, or pasted logs.
- ✅ Test local and internal services after changing VPN, proxy, DNS, or
NO_PROXYsettings. - ❌ Do not treat a registry mirror, a VPN, or a proxy as a universal fix for authentication, DNS, TLS, or project configuration errors.
- ❌ Do not run multiple concurrent downloads and compare them as though they were controlled tests.
For teams, keep shared configuration in reviewed documentation and keep personal credentials outside the repository. Document which settings belong to a laptop, a Docker daemon, a CI runner, or a container build. This avoids copying a developer’s private proxy endpoint into a project file and makes onboarding easier when a teammate works from another network.
Once the request succeeds, remove temporary overrides, repeat the original workflow, and check that the project still uses its expected lockfile and registry. If a change affects several tools at once, review it for unintended effects before making it permanent. A small, scoped adjustment is usually easier to audit and undo than a collection of global settings.