Quick Answer: gdirect is an open-source Rust command-line Google Drive downloader. It scans for Google front-end IPs your network can reach, sends Drive API and download traffic to them, and runs multi-connection, resumable transfers. Downloads default to 8 connections, can be set from 1 to 16, and are checked against Drive's MD5 after saving.
Most Google Drive downloads are slow or fail outright on some networks, and the usual fix, "just use a proxy," adds another hop you have to trust. The gdirect project, published on GitHub, takes a different route. It finds Google endpoints that answer from your network and connects to them directly, then splits each file across several connections. If you've ever watched a large Drive file crawl at 200 KB/s, this is the layer that matters.
Why the Route Matters More Than the Speed Setting
Most Google Drive downloaders start from a single HTTPS connection to the default Google hostname. On networks where that hostname is filtered or reset, extra connections don't help, because every one of them gets the same reset. The fix is at the routing layer, not the download layer.
gdirect splits its traffic into two paths. Drive API calls, downloads, uploads and token refresh go to a scanned Google IP. Sign-in and account verification (accounts.google.com, oauth2.googleapis.com, www.googleapis.com) still use your normal system network, with DNS and proxy. That split is deliberate: you only need the proxy for the one step that really needs a browser.
Here's the part most guides skip. The hostname and certificate check stay the same when gdirect uses a scanned IP. If connections carrying the real SNI get reset, gdirect retries under a forged identity: g.cn as the TLS name, with the real host in the Host header. The project credits the same idea as Sheas-Cealer, and it remembers which method worked per IP. So a reset doesn't just fail the transfer. It changes the next attempt.
How the IP Scan Decides What to Trust
The first transfer command checks a known relay and sweeps Google's own front ends. It keeps the working ones for 24 hours. The sweep is narrower than it sounds: it opens a TCP connection first, then fully verifies only the endpoints that answer, meaning TLS, a Drive API call and a test download. It stops after it has 8 verified endpoints.
Candidate addresses come from the range Google publishes as its own. The README says that list is goog.json minus cloud.json, embedded in the binary and refreshed weekly. Excluding Google Cloud ranges matters because it keeps the scan on front ends Google runs for its own services, not on customer VMs.
Certificates are checked against Google's GTS roots, which are embedded in the binary. They are not checked against your system CA bundle. That matters on machines with corporate or third-party CAs installed. A compromised third-party CA can't impersonate Google for gdirect this way.
The Relay Trade-off You Need to Understand
There's a catch, and the project documents it plainly. The relay at 183.56.143.147 is not Google. It forwards connections to Google, which is why it's fast and stable in mainland China, and why gdirect tries it first.
The relay can't read your traffic, because TLS runs end to end and is verified against Google's roots. But its operator can see your IP address. Unless the forged identity is used, it can also see which Google host you connect to.
If that's a problem for you, pass --google-only or set GDIRECT_GOOGLE_ONLY=1. gdirect then uses only Google's own front ends. The trade-off is that on some networks, fewer endpoints will answer. Check gdirect scan --list to see what your network can reach.
| Mode | Endpoints used | What the operator can see | Typical use |
|---|---|---|---|
| Default | Relay first, then verified Google IPs | Your IP; the Google host too, unless forged identity is used | Mainland China, where Google IPs are often blocked |
--google-only | Google's own published ranges only | Only Google's front ends | Privacy-sensitive use, or networks where the relay is unwanted |
--ip IP | One IP you choose | Whoever runs that IP | Testing a specific candidate |
Multi-Connection, Resumable Downloads in Practice
Downloads run one at a time in the queue, but each file can use several connections. The default is 8. You can set it per command with -j N, or change the saved default with +/- in the browse interface, within the range 1 to 16.
Resumability is simple to use. If a download or upload is interrupted, run the same command again. Finished downloads are recognised by checksum and reported as already downloaded, so you don't pay twice for the same file.
After saving, gdirect checks each file against Drive's MD5. That's a basic integrity check. It catches truncated or corrupted transfers. It won't detect a file that Drive itself stored wrong, and it doesn't apply to Google Docs, which are exported rather than stored as binary files. For those, use --export application/pdf and treat the result as a rendered copy, not the original.
Here's a common mistake. People raise connections to 16 on a shaky link and then wonder why throughput drops. More connections multiply the retry load on a flaky endpoint. If you see repeated resets, lower the count and let the route scan do its job.
Browsing, Mounting and Multiple Accounts
gdirect isn't only a downloader. The browse interface shows the parent folder, the current folder and a preview side by side, similar to yazi. You can mark items, copy or cut them, upload into folders and queue downloads without leaving the terminal.
The mount command uses rclone 1.75.2 or later. It runs on your normal system network, not the scanned IPs, so it needs a proxy in the same cases as sign-in. On macOS it uses the built-in NFS client, so you don't need a FUSE driver. Linux uses FUSE3. Writes go to a local cache first, and the cache tries to stay under 5 GiB. Open or unsent files can exceed that, so check the upload log before you unmount. The project says uploads are finished when the log shows to upload 0, uploading 0.
Multiple accounts work with the same OAuth client. You can sign in to several accounts, set a default with gdirect switch, and use -a for one command. Each account keeps its own folder cache and upload sessions. While your OAuth app is in Testing mode, every account needs to be added as a test user.
Frequently Asked Questions
what is a google drive downloader?
A Google Drive downloader is a tool that fetches files from your Drive account to a local disk. Standard browser downloads use one connection. Tools like gdirect use the Drive API, split files across several connections, and can resume after interruptions. gdirect is a terminal tool built in Rust and works on macOS, Linux and Windows.
how do i download a google drive file with gdirect?
Install gdirect, then run gdirect login --client-secret with a Desktop app OAuth JSON from your own Google Cloud project. After signing in, run gdirect download FILE_ID_OR_URL. The file saves to ./downloads by default. Use -o to choose a path, and -j N to set connections for one command.
why does a google drive download fail or stall on some networks?
Usually the default Google endpoint is reset or filtered on your network, so extra connections hit the same problem. gdirect scans for Google IPs your network can reach and retries under a forged TLS identity when the real SNI is reset. If transfers still fail, run gdirect scan --list to see the last error for each IP.
does gdirect need a proxy?
Sign-in does, if Google is blocked on your network. It needs browser access to accounts.google.com and application access to oauth2.googleapis.com and www.googleapis.com. During transfers, token refresh goes through the scanned IP, so no proxy is needed unless that IP fails to answer as Google's token endpoint.
Use It This Week and Check the Result
Start with one test. Sign in, run gdirect scan --list, and download a file you already know the size of. Compare the throughput at the default 8 connections with -j 4, and check that the MD5 verification passes. Then pass this to anyone on your team who is wrestling with a slow Google Drive download.