Strategies explained

# Discord and all other TLS
--lua-desync=hostfakesplit:host=www.google.com:tcp_ts=-1000:tcp_md5:repeats=4

# YouTube and Google
--lua-desync=fake:blob=tls_google:tcp_md5:tcp_seq=-10000:repeats=6
--lua-desync=multidisorder:pos=1,midsld

hostfakesplit

Cuts the packet exactly on the site name and substitutes a false name of the same length. The main consequence: the technique adapts to any ClientHello size. That is why it gets you not only to the Discord login page but also to the gateway, whose client hello is a different size. Strategies with a fixed overlap stumble here: login goes through, but there is no connection to the servers.

host=www.google.com

The name substituted for the real one. Harmless and certainly not blocked.

tcp_ts=-1000

The fake gets an older timestamp and is discarded on the server side by the PAWS mechanism. The value must be negative: with a positive one it is the real packet that gets discarded, not the fake.

tcp_md5

A second way to kill the fake, in case timestamps do not work. Chosen over badsum because it is safe behind a home NAT: the router does not drop such a packet in advance.

repeats=4

The fake is sent four times. The more repeats, the higher the chance the DPI notices it and remembers the connection as allowed.

fake + multidisorder

For YouTube the combination is different: first a fake ClientHello, then the real one, cut up and sent in reverse order. One technique usually does not punch through here; it is the combination that works.

pos=1,midsld

Two cut points: right after the first byte, and in the middle of the second-level domain. The second marker is mandatory: the engine strips pos=1 on its own, and the technique becomes a no-op.

When to use it. Always first. It is enabled by default and settles the question with most providers.

# Discord and other TLS
--lua-desync=hostfakesplit:host=vk.com:tcp_ts=-1000:tcp_md5:repeats=4

# YouTube: unchanged, as in the recommended one

host=vk.com

The only difference from the recommended strategy. TSPU treats domestic traffic more gently, and a "VK-flavoured" fake gets through where a "Google-flavoured" one is cut. This is a marked trend of recent years: other sets use Ozon or Sber's cloud for the same purpose.

YouTube stays on the google fake

Deliberately. A "VK-flavoured" fake is no good for Google's video servers: what is needed there is an ordinary working profile, and substituting the domain only gets in the way.

When to use it. Right after the recommended one, especially in the characteristic case: diagnostics is all green and Discord still will not open.

# Discord and other TLS: two fakes in a row
--lua-desync=fake:blob=tls_google:tcp_ts=-1000:repeats=6
--lua-desync=fake:blob=tls_vk:tcp_ts=-1000:repeats=6

# YouTube
--lua-desync=fake:blob=tls_google:tcp_ts=-1000:ip_id=zero:repeats=6

# voice: the domestic blob instead of google
--lua-desync=fake:blob=quic_vk:repeats=6

no splitting at all

The real packet is not touched in any way. All the work is done by fakes. That is exactly why this strategy often fixes media and voice: splitting sometimes only gets you into login, while further connections behave differently and break.

two fakes in a row

First a "Google" one, then a "VK" one right behind it. The bet is that at least one of the two suits that particular box. Cheap insurance: the surplus fake dies on the way regardless.

tcp_ts only

The single mechanism killing the fake. An important consequence follows: the strategy depends entirely on TCP timestamps being enabled. The program enables them itself for the session, but if it did not, the strategy would silently do nothing.

ip_id=zero

Zeroes the identifier field in the fake's IP header. An extra signal that some DPIs use to tell packets apart and handle them differently.

blob=quic_vk for voice

The voice junk is domestic too. On some networks this is exactly what fixes a ping of 5000 and "it connects but nobody can be heard".

When to use it. The classic case: Discord login goes through and then nothing. It will not connect to servers, attachments will not load, voice is silent.

# Discord
--lua-desync=fake:blob=tls_google:tcp_ts=-1000:repeats=6
--lua-desync=multisplit:pos=1,midsld:seqovl=681:seqovl_pattern=tls_google:optional

# other TLS: the same, but with a 664-byte overlap
# voice: quic_vk, as in ALT10

fake first, split second

The order is essential. The fake with the timestamp goes first and "prepares" the connection, and only then is the overlapping split applied. Without that preparation, a large overlap would break the connection to the gateway.

seqovl=681

The overlap: 681 bytes of foreign content are prepended to the start of the real packet, so the DPI and the server assemble the stream differently. For multisplit this is a number of bytes, not a position. In multidisorder the same parameter means something entirely different.

seqovl_pattern=tls_google

What gets prepended is not random junk but a real client hello from Google. A plausible beginning survives checks that random bytes do not pass.

:optional

If the split did not apply for some reason, the technique is skipped quietly rather than aborting the processing of the whole connection.

664 instead of 681

For the "other" profile the overlap is slightly smaller. The values were picked empirically in the original Flowseal set and carried over as they are.

When to use it. Right after ALT10, if that did not land. They are two variants of one idea by the same author.

# Discord
--lua-desync=multisplit:pos=2:seqovl=681:seqovl_pattern=tls_google:optional

# YouTube: the same plus ip_id=zero
# other: a 568-byte overlap

no fakes

A pure overlapping split, without a single forged packet. That means no fooling is needed at all, and the strategy depends neither on TCP timestamps nor on how the home router behaves. The least demanding of them all.

pos=2

One cut point, after the second byte. A second marker is not needed here, because the overlap does the main work rather than the cut itself.

When to use it. When the fake-based variants do not work. That is often a sign that the DPI inspects packets too thoroughly and simply does not believe fakes.

# the same for Discord, YouTube and everything else
--lua-desync=fake:blob=tls_google:tcp_ts=-1000:repeats=6
--lua-desync=fakedsplit:tcp_ts=-1000

fakedsplit

A split in which forged segments are inserted between the real ones. The key difference from multisplit: fooling is applied to the forged segments only, so tcp_ts is safe here. In multisplit it would hit the real segments too and break the connection.

the same for everything

The only strategy where all three TLS profiles use the same technique. Simple and predictable, which makes it a useful checkpoint while working through the list.

When to use it. If neither fakes on their own nor a pure split helped. Sometimes it is their combination that works.

# Discord and other TLS
--lua-desync=multisplit:pos=2,midsld-2:seqovl=1:seqovl_pattern=tls_google:optional
--lua-desync=wssize:wsize=1:scale=6

# YouTube: fake + multidisorder, as in the recommended one

wssize

The only strategy that works on the server's reply rather than on your request. A tiny receive window is advertised, the server is forced to deliver its reply in small portions, and the DPI cannot assemble a signature from it.

wsize=1:scale=6

The window size and the scaling factor. The combination gives a very small window on the first packets, after which it recovers.

the cost

Breaking up the reply means more packets and noticeably slower loading. That is a deliberate trade, which is why this strategy comes last among the combos.

midsld-2

A cut two bytes to the left of the middle of the domain. Offsets to markers are written like this.

When to use it. When it is specifically the login page that stubbornly will not open and nothing else helped. Be ready for it to be slower.

# a light split of the discord.media control connection
--filter-tcp=443-65535 --filter-l7=tls {HOSTLIST:discord}
--lua-desync=multisplit:pos=2,midsld-2:seqovl=1:seqovl_pattern=tls_google:optional
--new
# voice: a fake with a QUIC blob, no TTL limiting
--filter-udp=19294-19344,50000-65535 --filter-l7=discord,stun
--lua-desync=fake:blob=quic_google:repeats=6

this is not a combo

YouTube and other traffic are not touched at all. The strategy fixes one specific thing, and only that.

no ip_autottl

The main difference from the voice profile inside a combo. Picking a TTL depends on the route and gets in the way on some networks. There is none here; the fake is simply discarded by the server as junk.

repeats=6

More repeats than in a combo, because there is no second mechanism and everything rests on the DPI noticing the fake.

When to use it. Exactly one case: text in Discord works, but the voice channel is stuck connecting, the ping is 5000, or nobody can be heard.

--filter-tcp=443-65535 --filter-l7=tls {HOSTLIST:discord}
--in-range=-s5556 --out-range=-d10 --payload=tls_client_hello
--lua-desync=circular:fails=2:time=300
  # variant 1: hostfakesplit
  --lua-desync=hostfakesplit:host=www.google.com:tcp_ts=-1000:tcp_md5:repeats=4:strategy=1
  # variant 2: a double fake
  --lua-desync=fake:blob=tls_google:tcp_ts=-1000:repeats=6:strategy=2
  --lua-desync=fake:blob=tls_vk:tcp_ts=-1000:repeats=6:strategy=2
  # variant 3: fake plus overlap
  --lua-desync=fake:blob=tls_google:tcp_ts=-1000:repeats=6:strategy=3
  --lua-desync=multisplit:pos=1,midsld:seqovl=681:seqovl_pattern=tls_google:strategy=3:optional

circular

Not a technique but a manager: it switches variants itself when its detector catches a failure. A successful variant is left alone, and all of this happens on the fly, without restarting the engine.

fails=2:time=300

Switch after two failures; the counting window is 300 time units.

strategy=1, 2, 3

Variant labels. Numbering starts at one and runs without gaps. A single variant may contain several techniques, as variant 2 does.

three independently working variants

This is not a random set: 1 repeats the recommended strategy, 2 repeats ALT10, 3 repeats ALT11. In other words it cycles through three approaches, each of which works on its own for somebody.

--in-range is mandatory

Without a cache of incoming packets the detector cannot see a reset from the DPI, so there is nothing to switch on. Omitting this flag means getting a rotation that never rotates.

When to use it. When Discord specifically behaves erratically: sometimes it connects, sometimes it does not. Marked experimental because it depends on a manager that the engine loads from a separate library.