Արդյո՞ք դիտարկիչի պրոքսին ներառում է նաև WebRTC-ն

Դիտարկիչի HTTP պրոքսիի կարգավորումն ինքնաբերաբար չի տարածվում WebRTC-ի վրա։ IP ստուգման սովորական էջը չափում է վեբ հարցումը, իսկ զանգը միացման և հասցեների հայտնաբերման համար կարող է առանձին ուղիներ օգտագործել։

SOCKS5-ը չի վերացնում այդ տարբերությունը։ Chromium-ի ներկառուցված SOCKS5 URL պրոքսիի իրականացումն աջակցում է TCP-ին, ոչ թե ընդհանուր նշանակության UDP ասոցիացիային։ Արձանագրության հնարավորություններն ավելի լայն են, քան դիտարկիչի այդ միջերեսինը։

Դիտարկիչները WebRTC-ի համար առանձին ցանցային վերահսկիչներ են տրամադրում։ Chrome-ը գաղտնիության ընդլայնումների API-ով բացում է IP մշակման քաղաքականություն, այդ թվում՝ disable_non_proxied_udp։ Mozilla-ն նույնպես փաստաթղթավորում է WebRTC-ի ցանցային գաղտնիության կարգավորումները։ Chrome-ի այս արժեքը API-ի քաղաքականություն է, ոչ թե համընդհանուր նշատուփ կամ բոլոր հասցեները թաքցնելու երաշխիք։

Ստուգեք սովորական վեբ ելքը, ապա WebRTC-ի վարքը՝ իրականում օգտագործվող համաժողովի հավելվածում, այնպիսի ախտորոշիչով, որի զեկուցվող դաշտերը հասկանում եք։ Տեղային հասցեները, վերահաղորդիչի հասցեները և դրսից դիտարկված հանրային հասցեները կապի տարբեր մասերն են նկարագրում։ Գրանցեք դիտարկիչն ու փորձարկման պայմանները․ քաղաքականությունները, ընդլայնումները, գաղտնիության վարքը և հասանելի ուղիներն ազդում են արդյունքի վրա։ Ուստի ո՛չ «միշտ արտահոսում է» պնդումը, ո՛չ հաջող վեբ IP ստուգումը բավարար եզրակացություն չեն։

Եթե սահմանափակում եք WebRTC-ի որևէ ուղի, կրկին փորձեք անհրաժեշտ զանգերը։ Հասցեների բացահայտումը նվազեցնելը կարող է նաև խոչընդոտել զանգի միացմանը։ Այդ փոխզիջումն առանձին է այն հարցից, թե HTTP պրոքսիի վերջնակետը հասանելի է արդյոք։