Tri mënyra si Rusia ua prish serverin Xray, dhe vetëm njëra prej tyre është bllokim

Çdo pak javë mbërrin e njëjta tiketë. VPS-i i një klienti punonte nga Rusia, pastaj një ditë nuk punoi më, dhe tani adresa duket e vdekur nga Moska, ndërsa përgjigjet përsosmërisht nga kudo tjetër. Përfundimi shkruhet vetë: DPI-ja i mori gjurmët VLESS-it, serveri hyri në një listë, IP-ja u dogj.

Ndonjëherë kjo është saktësisht e vërtetë. Më shpesh është njëra nga dy gjëra të tjera që ndihen identike nga karrigia e klientit dhe kërkojnë rregullime krejt të ndryshme.

Kjo ka rëndësi, sepse këshilla e zakonshme — „ndërroje transportin në gRPC“ — është gjysmë e saktë në një mënyrë që e bën të vështirë për t'u kundërshtuar. Ajo vërtet ndihmon, për një arsye që ia vlen të kuptohet me saktësi. Thjesht nuk ndihmon për dështimin që ju kushton vërtet adresën, dhe shumë veta kapen pas saj në vend të asaj që do të ndihmonte.

Ja çfarë po ndodh në të vërtetë, sipas radhës së dëmit që bën.

1. Skanimi: serveri juaj i përgjigjet një sonde, dhe përgjigjja e tradhton

Kjo është ajo që vërtet ju kushton gjithë IP-në.

Në maj 2026 dikush e vuri një skaner VPN-esh të stilit rus kundër serverit të vet dhe e publikoi raportin. Është dokumenti më i dobishëm për këtë temë, sepse tregon arsyetimin e jo verdiktin. 7

Skaneri nuk kufizohet te porta 443. E përshkon gjithë intervalin e portave, nga 1 te 65535, me 500 fije, dhe u hedh disa sonda të ndryshme të gjithave që përgjigjen: një GET HTTP, një CONNECT, një ClientHello TLS me një SNI qëllimisht të pavlefshme, dhe binar të papërpunuar. Pastaj i krahason përgjigjet.

Një server i vërtetë uebi reagon ndryshe ndaj plehrave të ndryshme. Një proxy me një fallback statik jo. Në serverin e testuar, porta 2096 ktheu të njëjtat 41 bajt, bajt për bajt, ndaj çdo sonde, duke nisur me rreshtin e statusit HTTP/0.0 307 Temporary Redirect. Asnjë nginx, Apache apo Caddy i vërtetë nuk nxjerr version HTTP/0.0. Ajo përgjigje e vetme është thuajse rrëfim.

Raporti grumbullon disa shenja të tjera më të buta:

• Asnjë header Server:. Çdo server kryesor uebi e vendos një të tillë. Mungesa e tij thotë „trajtues i personalizuar“, jo „faqe interneti“.
• Një certifikatë me gjashtë ditë vlefshmërie të plotë. CA-të publike lëshojnë për 30 deri 90 ditë. Çdo gjë nën rreth dy javë thotë „e bërë me dorë“, çka thotë „stend testimi“, çka thotë „proxy“.

Skaneri e vlerësoi hostin me 48 nga 100 dhe ktheu verdiktin OBVIOUSLY-VPN. Pasoja, me fjalët e vetë raportit, është se anomalitë e grumbulluara e kalojnë pragun e TSPU-së dhe „IP-ja shtohet në listën e reputacionit dhe rrjedhat e ardhshme hidhen poshtë ose ngadalësohen derisa të ndryshojë nënshkrimi“.

Ky është mekanizmi që kanë ndër mend njerëzit kur thonë se IP-ja u bllokua. Është i vërtetë, është në nivel adrese, dhe nxitet nga ajo që thotë serveri juaj kur i flitet — jo nga protokolli që po tuneloni.

2. Shpërthimi: tri handshake brenda pesëdhjetë milisekondash

Mekanizmi i dytë është i sjelljes dhe nuk ka të bëjë fare me sondimin.

Një temë e hapur kundër Xray-core përshkruan se si TSPU-ja e lexon ClientHello-n e TLS-së dhe e vlerëson sipas nënrrjetit dhe sistemit autonom të serverit, sipas SNI-së dhe sipas gjurmës së shfletuesit. Gjurmët e Chrome-it, Safari-t dhe iOS-it nga një interval i dyshimtë mbahen; Firefox-i, Android-i, OkHttp-ja dhe Edge-i kalojnë. 3

Ajo që e nxit është intensiteti. Tri ose më shumë lidhje TLS të njëkohshme drejt të njëjtit host brenda rreth 20 deri 50 milisekondash i ngrijnë të gjitha për rreth 120 sekonda. Nëse klienti përgjigjet duke e rrotulluar gjurmën gjatë ngrirjes, kjo bëhet 600 sekonda.

Prandaj një shfletues që hap një faqe përmes tunelit është shumë më keq se një shkarkim i vetëm. Shfletuesit modernë hapin gjashtë lidhje njëherësh nga vetë dizajni. Kjo është pikërisht forma që po kërkon zbuluesi.

3. Numëruesi: kilobajti juaj i pesëmbëdhjetë

I treti është më i vrazhdë dhe, në terma të vetët, elegant. Censori e vëzhgon një lidhje TLS drejt një serveri të huaj dhe e ngrin sapo të dhënat e kthyera kalojnë rreth 15 deri 20 KB — më vonë e përcaktuar si rreth 25 paketa në secilin drejtim.

Tema që e dokumenton, hapur më 27 qershor 2025, është e qartë se ky nuk është përputhës protokolli: „Nuk ka rëndësi nëse është trafik HTTPS ‚legjitim' apo nëse dikush po e imiton.“ 2

Ky është raportimi „punon për disa sekonda dhe pastaj vdes“. Një handshake dhe një-dy kërkesa të vogla hyjnë brenda buxhetit. Një faqe me imazhe jo.

Si t'i dallosh, me një test të vetëm

Të tria duken njësoj sepse censori i ngrin lidhjet e nuk i rivendos. Pa RST, pa ICMP — handshake-u thjesht nuk përfundon kurrë dhe klienti rri aty derisa t'i skadojë koha, çka është e padallueshme nga një rrugë e hedhur në zi.

Nga rrjeti i prekur, merrni diçka të vogël e të thjeshtë përmes HTTP-së nga e njëjta adresë.

• HTTP-ja e thjeshtë punon, TLS-ja jo — mekanizmi 2 ose 3. Adresa është mirë. Në një raportim të nëntorit 2025 për bllokimin e REALITY-t te një ISP rus, raportuesi e kontrolloi pikërisht këtë dhe gjeti se faqja në të njëjtën IP ende ngarkohej. 4
• Nuk përgjigjet asgjë fare — mekanizmi 1. Jeni në listën e reputacionit dhe e vetmja gjë që ndihmon është një adresë e re.

Dallimi i vlen ato dy minuta, sepse zëvendësimi i një serveri për mekanizmin 2 ose 3 ju blen rreth pesëmbëdhjetë kilobajt lehtësim para se adresa e re të sillet njësoj. Njerëzit e lexojnë këtë si djegie të menjëhershme të IP-së së re. Nuk u dogj asgjë. Buxheti thjesht u shpenzua sërish.

Ku ndihmon vërtet gRPC-ja, dhe ku jo

Operatorët vazhdojnë të raportojnë se gRPC-ja mbijeton me javë të tëra në lidhje ku TCP-ja e thjeshtë zbulohej brenda ditësh. Kjo nuk është folklor, dhe nuk është fat. Është mekanizmi 2, dhe arsyeja është mekanike.

gRPC-ja punon mbi HTTP/2, dhe dokumentacioni i Xray-t është i qartë se çfarë blen kjo: „gRPC (HTTP/2) ka multipleksim të integruar. Nuk rekomandohet të aktivizohet mux.cool kur përdoret gRPC dhe HTTP/2.“ 5

Multipleksimi do të thotë se shumë rrjedha ndajnë një lidhje të vetme TCP, e rrjedhimisht një handshake të vetëm TLS. Zbuluesi i shpërthimeve po kërkon tri ose më shumë handshake drejt të njëjtit host brenda pesëdhjetë milisekondash. Një shfletues mbi TCP të thjeshtë hap gjashtë lidhje dhe prodhon pikërisht atë formë. I njëjti shfletues mbi gRPC prodhon një handshake me gjashtë rrjedha HTTP/2 brenda tij. Nuk mbetet shpërthim për t'u zbuluar.

Pra nëse kaluat te gRPC-ja dhe problemi juaj u zhduk, kjo është arsyeja, dhe nuk duhet ta lini askënd t'ju bindë të ktheheni prapa.

Ajo që nuk bën është t'i përgjigjet një sonde. E njëjta faqe paralajmëron se „shërbimet gRPC janë në rrezik nga sondimi aktiv“, dhe rekomandon një reverse proxy përpara që e ndan trafikun sipas parashtesës së shtegut. gRPC-ja e zhveshur që dëgjon në 443 prapëseprapë i përgjigjet skanerit, dhe mekanizmi 1 është ai që e vë adresën në listën e reputacionit. Multipleksimi nuk bën asgjë për këtë.

Ia vlen gjithashtu të dihet se ku po shkon kjo punë. Transporti gRPC është i zhvlerësuar: dokumentacioni tani thotë „Rekomandohet të kaloni te XHTTP.“ 5 Kjo është shënim migrimi, jo arsye për ta shkulur diçka që punon. XHTTP-ja, e futur në dhjetor 2024, multiplekson në të njëjtën mënyrë përmes XMUX-it dhe shton atë që i mungon gRPC-së — mbushje header-ash, dhe një ndarje mes rrjedhës lart e asaj poshtë, kështu që rrjedha poshtë udhëton mbi kërkesa GET të pavarura, çka i shmang gjithashtu kufijtë gRPC që vendosin disa CDN. Përballë WebSocket-it, ajo e shmang ALPN-në e dukshme http/1.1. 6

Planifikojeni kalimin. Mos e nxitoni.

Mblidhini mbi njëra-tjetrën; nuk janë alternativa

Gabimi poshtë shumicës së këtyre debateve është ta trajtosh këtë si zgjedhje të vetme — REALITY ose gRPC, ky transport ose ai tjetri. Tre mekanizmat janë të pavarur, prandaj janë edhe mbrojtjet, dhe ato kombinohen:

Një server që mban REALITY-n pas nginx-it mbi një transport të multipleksuar u përgjigjet të treve. Një server që mban vetëm njërin prej tyre i përgjigjet njërit.

Vendosni një nginx të vërtetë përpara, dhe drejtojini fallback-et nga ai. Ky është ndryshimi me vlerën më të lartë, dhe është rekomandimi i parë i vetë raportit: mbani një nginx të vërtetë me një hartë të rregullt faqesh gabimi dhe drejtojini fallback-et e Xray-t nga ai, që çdo gjë që nuk është handshake i vlefshëm të marrë HTTP të vërtetë nga softuer i vërtetë serveri uebi. 7 Kjo e vret rreshtin e statusit HTTP/0.0, e rikthen header-in Server: dhe i bën përgjigjet të ndryshojnë sipas kërkesës, ashtu siç bëjnë ato të një faqeje interneti. Shërbeni një site të vërtetë mbi të. Një faqe mirëseardhjeje e parazgjedhur e nginx-it është më mirë se një 307 statike, dhe një site i vërtetë është më mirë se të dyja.

Përdorni një certifikatë të vërtetë. Let's Encrypt me rinovim automatik. Një certifikatë gjashtëditore e vetënënshkruar është shenjë më vete, dhe heqja e saj nuk kushton asgjë.

Kini kujdes SNI-në. Huazimi nga Microsoft-i, Apple-i ose Google-i tërheq vëmendje; hostet e brendshëm me trafik të lartë raportohet të jenë shumë më të qëndrueshëm si objektiv për t'u vjedhur. Bllokimi është selektiv e jo me shenjë të përgjithshme, dhe një nëndomen i freskët në një adresë të pastër shpesh kalon. 8

Kini kujdes gjurmën, por jo vetëm gjurmën. Kalimi i uTLS-së nga Chrome te Firefox raportohet ta ketë rikthyer lidhshmërinë te operatorë ku Chrome-i mbahet. 8 Por vlerësimi peshon gjithashtu nënrrjetin dhe AS-në, prandaj një gjurmë e përsosur në një interval me vlerësim të keq mbetet lidhje e keqe.

Përdorni një transport të multipleksuar, dhe lëreni të multipleksojë. gRPC ose XHTTP, me mux.cool të fikur — dokumentacioni është i qartë se aktivizimi i tij mbi HTTP/2 nuk rekomandohet. Nëse e mbani gRPC-në pas nginx-it, kjo është grpc_pass me një parashtesë shtegu, çka ju jep mbrojtjen ndaj sondës dhe atë ndaj shpërthimit nga një vendosje e vetme.

Mos lini asgjë tjetër në makinë të flasë. Skaneri i përshkon të 65535 portat. Çdo shërbim që përgjigjet është edhe një shans për të grumbulluar një anomali. Zhvendoseni SSH-në nga porta 22 në një portë të lartë dhe mbylleni me mur zjarri drejt adresave të njohura.

Mbani një vendndodhje të dytë. Jo një adresë rezervë në të njëjtin interval për t'u rrotulluar — diku vërtet tjetër. Kur dështimi është rajonal, ajo që ndihmon është një rrugë tjetër, jo një numër tjetër në të njëjtën rrugë.

Dhe prisni që kjo të vazhdojë të lëvizë

Roskomnadzor-i e bllokoi VLESS-in në fund të vitit 2025 duke përdorur TSPU-në, dhe shumica e ofruesve u përgjigjën duke shtyrë konfigurime të reja brenda ditësh. 1 Ky është ritmi në të cilin është ulur kjo punë, dhe buxheti pas saj po rritet: kapaciteti i TSPU-së planifikohet të rritet dy herë e gjysmë deri në vitin 2030, në 954 terabit për sekondë, me rreth 186 milionë $ — mjaftueshëm, sipas llogarive të vetë Ministrisë, për të analizuar gjithë trafikun e Runet-it dhe për të tepruar.

Asnjë prej këshillave më sipër nuk është e përhershme. Dy gjëra përgjithësohen.

Nuk po kapeni për atë që tuneloni. Po kapeni sepse dukeni si makinë që ekziston për të tuneluar — në atë që përgjigjet, në mënyrën si lidhet dhe në sasinë që dërgon. Çdo gjë që e bën serverin të duket si server uebi i zakonshëm që rastësisht bart edhe trafik tjetër ju blen kohë.

Dhe asnjë cilësim i vetëm nuk është përgjigjja. Zbulimi është me shtresa, prandaj edhe mbrojtja duhet të jetë. Nëse dikush ju thotë se një transport i vetëm e zgjidh këtë, pyeteni se cilin nga të tre e zgjidh.

Burimet

1. Russia's internet censorship in 2026: VPN crackdowns, mobile shutdowns, Telegram blocks and the state messenger Max, Zona Media, 7 prill 2026
2. [Russia] Censor has a new method of blocking, net4people/bbs, hapur më 27 qershor 2025
3. Russia blocks 2026, XTLS/Xray-core, 2026
4. TCP + Reality gets blocked, XTLS/Xray-core, 23 nëntor 2025
5. gRPC transport, dokumentacioni i Project X
6. XHTTP, XTLS/Xray-core, dhjetor 2024
7. How Bye Bye VPN Works in Russia, MHSanaei/3x-ui, 6 maj 2026
8. Bypassing Russian GFW, XTLS/Xray-core