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
  tun-helper.exe       elevated helper for TUN mode (no console; spawned by TorJet.exe)
  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
  tun2socks.exe        TUN mode: routes system traffic through the tor SOCKS proxy
  wintun.dll           Wintun driver used by tun2socks
  xray.exe             optional: TLS fragment proxy (see Fragment toggle)
  xray\config.json     xray config - edit freely, TorJet just runs it as-is
                       (ships with the release; source: configs\xray-config.json)
  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\)
   • 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
   • Fragment (xray) — routes all tor relay TLS through a local xray.exe SOCKS proxy that fragments the TLS ClientHello (a common circumvention technique against SNI/length-based DPI). Default on when data\xray.exe is present; toggle it in Settings. Also settable via --fragment / --no-fragment.
   • 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, 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, 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 30) — 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. 0 = off. Your choices are remembered for next time (data\mode.txt, data\strategy.txt, data\conflux-sets.txt, data\conflux-linked-sets.txt, data\conflux-legs.txt).
3. On 100% bootstrap Tor is running. The system proxy is NOT changed automatically — press P to toggle it on/off (HTTP 127.0.0.1:8118). Press T to toggle TUN mode (see below). 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). 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, TUN mode and the core) and return to the main menu. SOCKS5 is at 127.0.0.1:9050 and DNS at 127.0.0.1:53530.

TUN mode (all traffic through Tor)

Press T to route all of the system's IPv4 traffic through Tor, not just proxy-aware apps. It needs Administrator: on the first press Windows shows a UAC prompt (launcher runs the elevated tun-helper.exe helper). To turn it off press T again (or run TorJet.exe --tun-off).

How it works:

• Creates a Wintun adapter named TorJetTun (tun2socks.exe + wintun.dll) and points the default route into it, so all system traffic goes to the local tor SOCKS proxy.
• Points system DNS at 127.0.0.1:53 (tor's DNSPort, enabled with a config reload); port 53 must be free.
• Adds a /32 route on the physical interface for every relay IP from the cached consensus and bridges, so tor's own relay connections bypass the tunnel (without this tor's outbound traffic would loop back into itself). These are refreshed every 2 minutes from a fresh consensus.
• TUN turns off automatically if tor stops, the helper exits, or the tunnel process dies; system DNS and routes are restored.

Notes:

• TUN mode and the P-proxy are independent — you can use either, both, or neither.
• While TUN is on, only IPv4 is tunnelled (IPv6 is untouched).

You can also launch with fixed settings:

TorJet.exe obfs4               start directly in obfs4 mode
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 obfs4 aggressive tun     start + auto-enable TUN mode
TorJet.exe --fragment          enable the tlshello fragment (xray)
TorJet.exe --no-circuit-watch  disable the circuit health monitor (on by default)
TorJet.exe --watch-rtt-pct 30  close a set's slowest N% of legs by RTT (default 30)
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 --tun-off           turn TUN mode off (same as pressing T twice)
TorJet.exe --tun-status        print whether TUN mode is on or off
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 proxy	Windows system proxy (pressed P)
53530	DNS	system DNS resolver (TUN mode)

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 proxy 127.0.0.1:8118. These ports belong to tor itself — they are the front door. Everything you send there enters the Tor circuit.

Port 10808 is internal: it is xray's SOCKS listener and you must not connect your browser to it.

When Fragment (xray) is on, tor's own relay connections are routed through xray:

your browser
   │  SOCKS5 127.0.0.1:9050   (tor's SocksPort)
   ▼
tor.exe
   │  tor wants to open TLS to a guard/bridge
   │  torrc line: Socks5Proxy 127.0.0.1:10808
   ▼
xray.exe 127.0.0.1:10808      (internal - NOT for the browser)
   │  two stacked fragment passes: first splits the TLS ClientHello
   │  ("tlshello"), then re-splits the remaining stream in 1-byte pieces
   ▼
real guard/bridge IP over the Tor network
   ▼
circuit  guard -> middle -> exit
   ▼
destination

So xray sits between tor and the Tor network, never between your browser and tor. Without data\xray.exe the Socks5Proxy line is simply not written and tor connects directly. With it, the first TLS handshake to your guard/bridge no longer reveals Tor's distinctive ClientHello (SNI, length pattern), which is how some ISPs detect and block Tor.

TUN mode traffic

Press T and all system traffic is captured by a virtual adapter (TorJetTun, 10.0.0.1/24):

all apps
   │  default route -> TorJetTun adapter
   ▼
tun2socks.exe  (transparent TCP -> SOCKS5)
   │  SOCKS5 127.0.0.1:9050
   ▼
tor.exe -> (xray fragment if enabled) -> Tor network -> exit -> destination

tor's own relay connections are exempted with per-relay /32 host routes on the physical interface, so tor's outbound TLS never loops back into the tunnel.

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 30%), 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 10), 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 7-9) — 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\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.

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, tun2socks, wintun, xray) keep their own licenses.