Skip to content

Latest commit

 

History

180 Commits

Folders and files

NameName
Last commit message
Last commit date
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

TorJet

TorJet is a single-folder, portable Tor client tuned for maximum download/upload throughput (padding disabled, faster bootstrap, longer circuit reuse). Built in CI from the official tor 0.4.9.11 sources plus pluggable transports (obfs4, webtunnel, snowflake). No installation and no %APPDATA% — every file and all runtime state stays inside one folder, so you can copy or move it anywhere.

Layout

TorJet.exe          double-click to start; asks for a connection mode
data\
  tor.exe              + DLLs, geoip, geoip6, transports
  torrc.template       base config (relative paths; sits next to tor.exe)
  torrc                generated by TorJet.exe from the chosen mode
  bridges\             obfs4_tested.txt, webtunnel_tested.txt, vanilla_tested.txt, snowflake_tested.txt
  data\                runtime state (cached consensus, keys, tor.log)

Usage

  1. Download torjet-win64-vX.Y.Z.zip from GitHub Releases (or the torjet-win64 artifact from GitHub Actions) and unzip.
  2. Double-click TorJet.exe. The main menu lets you pick:
    • Connection mode — Direct (no bridges, when Tor isn't blocked), WebTunnel, Obfs4, Vanilla, Snowflake (bridges from data\bridges\), Memory (reconnect with last successful mode + strategy)
    • Strategy level — a packaged torrc tuning bundle, from most compatible to fastest:
      1. standard — stock config, most compatible
      2. balanced — long-lived reused circuits (fewer handshakes)
      3. aggressive — more guards + faster scheduler + deeper reuse
      4. ultimate — max concurrency + greedy (Vanilla) scheduler
      5. lowlatency — lowest ping: KISTLite pacing and RTT set filters (skip ≥400 ms, best 20%)
    • The shipped default strategy is ultimate — if no data\strategy.txt exists yet, TorJet picks the fastest preset.
    • Conflux topology (from the Settings submenu) — how many conflux circuit sets tor keeps:
    • Conflux sets (ConfluxNumSets, 0=consensus default) — how many sets to keep alive. The total (linked + building) is held exactly at this many, so the count matches what you set. Each set is one exit path.
    • Conflux legs (ConfluxNumLegs, 0=consensus default) — legs per set; more legs = more parallel bandwidth per set.
    • Conflux linked (cap) (ConfluxNumLinkedSets, 0=consensus default) — ceiling on linked sets; it only binds when set below Conflux sets (e.g. cap 4 with 5 sets keeps at most 4 linked).
    • Skip slow sets (RTT) (ConfluxSetRttMax, default 400 ms, 0=off) — when a new stream is attached, sets whose best-leg RTT is at/above this many milliseconds are skipped (a slow-set failover).
    • Best % of sets (RTT) (ConfluxSetRttPct, default 20%, 0=off) — when a new stream is attached, only the best (lowest-RTT) this-many percent of sets are used; e.g. 25 keeps the top quarter. Applied after the RTT skip above, and always keeps at least one set.
    • Weak legs (top %) (--watch-rtt-pct, default off) — the circuit health monitor closes the top this-many percent of linked legs with the highest RTT compared globally across every set (fully relative, no absolute ms threshold); the single best leg in the pool is never closed and the pool is never fully pruned. Off by default: the 2026-08 bench campaign showed the RTT filters cost 30-50% sustained download on this network — pick the lowlatency preset (or set item 9) to trade some throughput for lower ping. Your choices are remembered for next time (data\mode.txt, data\strategy.txt, data\keepalive.txt, data\conflux-sets.txt, data\conflux-linked-sets.txt, data\conflux-legs.txt, data\conflux-selection.txt, data\conflux-set-rtt.txt, data\conflux-set-rtt-pct.txt, data\circuit-watch-pct.txt). The user's pre-TorJet system-proxy settings are saved to data\proxy-backup.txt while the proxy is on and restored from there even after a crash.
  3. On 100% bootstrap Tor is running. The system proxy is NOT changed automatically — press P to toggle it on/off (HTTP CONNECT tunnel, 127.0.0.1:8118). Press S to run a speed test: single-stream over the HTTP proxy, or the max test which opens several parallel SOCKS5 streams, each authenticated with a unique username so tor's isolation gives every stream its own circuit (the true multi-path throughput ceiling) — download and upload are measured separately. Press D for conflux details, A to add a leg to a set, L (or V) to view the logs, and C to stop Tor (system proxy + core) and return to the main menu. SOCKS5 is at 127.0.0.1:9050 and DNS at 127.0.0.1:53530.

You can also launch with fixed settings:

TorJet.exe obfs4               start directly in obfs4 mode
TorJet.exe memory             reconnect with last successful mode + strategy
TorJet.exe auto                race vanilla/obfs4/webtunnel in parallel and
                               keep the first that bootstraps (CLI)
TorJet.exe obfs4 aggressive    start in obfs4 mode + strategy level
TorJet.exe --strategy ultimate start with the ultimate strategy
TorJet.exe obfs4 aggressive proxy   start + auto-enable the system proxy
TorJet.exe --no-circuit-watch  disable the circuit health monitor (on by default)
TorJet.exe --no-watchdog       disable the auto-restart watchdog (on by default)
TorJet.exe --watch-rtt-pct 30  close a set's slowest N% of legs by RTT (default off)
TorJet.exe --watch-strikes 1   weak passes before a leg is closed (default 1)
TorJet.exe --watch-interval 10 check circuits every N seconds (default 10)
TorJet.exe --watch-cooldown 20 seconds between closes (default 20)
TorJet.exe --newcircuit        request a new identity (NEWNYM)
TorJet.exe --update-bridges    re-download the bridge lists from the
                                  Tor-Bridges-Collector repo and replace them
                                  in data\bridges\
TorJet.exe --stop              stop Tor and restore the proxy
TorJet.exe --bootstrap-only    boot to 100% then stop (no proxy change)
TorJet.exe --conflux-status    print the conflux set/leg/linked status
TorJet.exe --conflux-add [set] add a leg to a conflux set
TorJet.exe --conflux-check     boot, wait for conflux to build, then report
TorJet.exe --bench             headless throughput benchmark (see scripts\bench.ps1)

In the background TorJet also checks GitHub for a newer release every 30 minutes and prints a download link when one exists.

How traffic flows

TorJet exposes three local entry points, all bound to 127.0.0.1:

Port Purpose Who uses it
9050 SOCKS5 proxy your browser / apps
9052 keep-alive SOCKS5 (internal) TorJet's background pings
8118 HTTP CONNECT tunnel proxy (HTTPTunnelPort — CONNECT only, not a full HTTP proxy) Windows system proxy (pressed P)

Auto race mode (TorJet.exe auto or the default GUI mode)

In auto mode TorJet launches three tor instances side by side — vanilla, obfs4 and webtunnel — each with its own data directory and listener ports:

Racer SOCKS HTTP DNS Control
vanilla 9150 8150 61530 9151
obfs4 9250 8250 62530 9251
webtunnel 9350 8350 63530 9351

The first instance to reach 100% wins and the other two are stopped. The winner keeps running on its own racer ports — TorJet re-points the whole session (control port, keep-alive, watchdog, speed test) at those ports, so the tunnel is live immediately with zero restart and the system proxy is set to that winner's HTTP port. The exact ports are shown on screen when the session comes up. Because the addresses are dynamic in this mode, point your apps at the SOCKS5/HTTP ports printed by the session (the fixed 9050/8118 below apply to fixed single-mode starts).

Point your browser (or any app) at the SOCKS5 proxy 127.0.0.1:9050, or press P to set Windows' system proxy to the HTTP CONNECT tunnel on 127.0.0.1:8118. These ports belong to tor itself — they are the front door. Everything you send there enters the Tor circuit:

your browser
   │  SOCKS5 127.0.0.1:9050   (tor's SocksPort)
   ▼
tor.exe  ->  TLS to guard/bridge
   ▼
real guard/bridge IP over the Tor network
   ▼
circuit  guard -> middle -> exit
   ▼
destination

Tunneling apps that don't support proxy

Some applications (games, CLI tools, etc.) don't have built-in proxy settings. You can route their traffic through Tor using V2rayN as a TUN wrapper:

  1. Start TorJet and wait for 100% bootstrap.
  2. Open V2rayN and add a new server with this address:
    socks://Og@127.0.0.1:9050#TorJet
    
  3. Select the TorJet server and enable Tun mode.

V2rayN will create a virtual network interface that captures all system traffic and sends it through TorJet's SOCKS5 proxy (127.0.0.1:9050).

Circuit health monitor

While Tor is up, TorJet watches the conflux legs via the control port. Every 10 s it asks tor for the conflux set list (CONFLUX QUERY) and prunes low quality legs so tor rebuilds them with fresh circuits:

  • a linked leg is weak when it ranks in the top --watch-rtt-pct% of ALL linked legs across every set by RTT (the slowest legs of the whole pool; default 25 — set it in Settings item 9 or with --watch-rtt-pct), so the pruning is fully relative and adapts to the network with no absolute ms threshold — a set with a single slow leg is pruned just like the weak legs of a multi-leg set;
  • a leg must stay weak for --watch-strikes consecutive passes (default 1) before it is closed, so a single bad measurement closes it right away;
  • the single best (lowest RTT) leg in the whole pool is never closed, and the pool is never fully pruned;
  • legs stuck unlinked for --watch-unlinked-strikes passes (default 4) AND older than --watch-unlinked-grace seconds (default 120) are closed as dead weight, but never in the first 90 s after bootstrap while everything is still building;
  • at most --watch-max-per-pass legs (default 6) are closed per pass so replacement builds don't pile up.

tor launches a replacement leg for every closed leg (sets below the configured ConfluxNumLegs target are also topped up with CONFLUX ADD), and conflux migrates streams onto the fresh circuits. When a weak leg was the last (sole) leg of its set, tor rebuilds the set itself with a fresh leg for the same set id, so even 1-leg sets keep recovering. A 20 s cooldown between closes keeps the circuit set stable (relaxed during the first 90 s after bootstrap). After every close pass a summary report is printed to the console (legs closed, circuit ids, and the current conflux set/leg/linked counts). Disable it with --no-circuit-watch; tune it with --watch-rtt-pct <percent>, --watch-interval <seconds>, --watch-cooldown <seconds> and the other --watch-* flags. The weak-leg percentage can also be changed from the settings menu (item 9), saved to data\circuit-watch-pct.txt.

Keep-alive

Once bootstrap hits 100%, TorJet starts a permanent keep-alive: a lightweight generate_204 ping is dispatched every second through a dedicated keep-alive SOCKS5 port (127.0.0.1:9052, NoIsolateSOCKSAuth) on the same tor instance you test, so a healthy report is not a false positive. Each request is allowed up to 5 s for a response and is recorded as ok / fail / timeout. Because the pings use a fixed SOCKS5 auth username, tor recognizes them and always spreads them evenly across every conflux set (each ping lands on the set that has seen the fewest streams, so the spread stays balanced even while sets are being rebuilt), bypassing the set-selection policy and the RTT filters (settings items 6-8) — so keep-alive traffic keeps exercising all sets even when the slow-set filters would normally skip them. The loop runs in the background while the menu is served (so the menu appears immediately) and stops only when you press C, tor exits, or the app is closed. It keeps circuits warm and honest: if tor dies, the pings start failing (details go to data\jet.log). The old 1 MiB download check was replaced: it gave false negatives on cold single-stream circuits and added ~1 MiB of padding traffic. During the first 90 s after bootstrap the monitor's close cooldown is relaxed, so weak legs are replaced immediately.

Watchdog (auto-restart)

An independent probe pings the tunnel every 15 s (after a 90 s post-bootstrap grace window). Four consecutive failures mean tor is hung: the launcher kills it, rebuilds the circuit monitor and keep-alive and boots tor again — up to 3 attempts. Disable with --no-watchdog.

Android

A full Android port lives in android/ and builds in CI via .github/workflows/build-android.yml (branch android). It keeps the same Windows appearance: dark theme, the big clickable power ring (green connected / amber connecting / red restarting), the SOCKS/HTTP endpoint line, the PROXY toggle and the SETTINGS rows (Mode, Auto proxy, Strategy level, Conflux sets, Conflux legs, Linked-set cap, Keep-alive, Set select, Skip slow sets (RTT), Best % of sets, Weak legs (top %)).

  • android/ — Gradle project (Kotlin, arm64-v8a)
    • app/src/main/java/com/torjet/app/ — Kotlin port of the core: TorController (spawn/stop tor, torrc generation), TorrcBuilder (mirrors torrc.jet + the strategy table), SettingsStore, control-port client, keep-alive, speed test, VpnProxyService (the Android stand-in for the Windows system proxy), and the ring-based UI (MainActivity, PowerRingView, SettingsActivity).
    • scripts/build-android-tor.sh — NDK cross-compile of tor (headers, deps, geoip) into a static aarch64 executable.
  • The tor binary, geoip files, pluggable transports and bridge lists are cross-compiled/copied into android/app/src/main/assets/native/ by CI and extracted + chmod +x at first launch.
  • SOCKS5 still listens on 127.0.0.1:9050; the PROXY toggle runs a VpnService that routes the whole device over that SOCKS port (each stream gets its own circuit via unique SOCKS auth username).
  • Build the APK locally with:
    cd android && ./gradlew assembleRelease
    

Building

.github/workflows/build.yml builds tor + transports and publishes the torjet-win64 artifact on every push.

  • tor-src\ — official tor 0.4.9.11 source with TorJet's conflux extensions (the CONFLUX control command, the ConfluxNumSets / ConfluxNumLegs / ConfluxNumLinkedSets / ConfluxSetRttMax / ConfluxSetRttPct torrc options, and launch-budget refund + auto-relaunch after a leg is closed)
  • configs\torrc.jet — speed-optimized portable config template (becomes data\torrc.template)
  • bridges\ — tested bridge lists shipped with the release
  • scripts\start-tor.cs — source of TorJet.exe (compiled with scripts\build-start-tor.ps1)
  • scripts\bench.ps1 — headless benchmark harness driving TorJet.exe --bench (1/4/8 parallel streams, CSV output per run)

License

The TorJet Core (launcher source, configs, and build scripts) is licensed under the TorJet Core License v1.0 — see LICENSE.

In short: you may use, modify, and embed the Core in your own program only if you (1) display a prominent link to https://github.com/Delta-Kronecker/TorJet on the main page/screen of your program and/or its repository, and (2) state explicitly next to it:

This software uses the TorJet core, obtained from https://github.com/Delta-Kronecker/TorJet

Derivatives must be released under the same license (share-alike, including network/SaaS use), and any breach terminates the license automatically.

Third-party components shipped with TorJet (tor, pluggable transports) keep their own licenses.

About

modified tor core for best speed

Topics

Resources

Stars

5 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages