libproxy-ն ընտրում է երթուղի, ձեր հաճախորդը՝ կապը
Օգտագործեք libproxy-ի արդյունքները որպես URL-ական երթուղու թեկնածուներ՝ փոխարենը սպասելու, որ հայտնաբերումը կվերահասցեավորի հավելվածի սոկետները։
Եթե libproxy-ն վերադարձնում է փրոքսի URI, մինչ հաջորդ սոկետը միանում է ուղղակիորեն, ստուգեք հանձնումը։ libproxy-ն հայտնաբերում է քաղաքականություն. այն չի ընդհատում հավելվածի բացած ամեն սոկետ։
- Հարցրեք ռեսուրսի մասին։ Փաստաթղթավորված libproxy 0.5 C API-ում ստեղծեք փրոքսի գործարան և հարցրեք իրական նպատակակետ URL-ը։
- Մեկնաբանեք դասավորված թեկնածուներին։ HTTP-, SOCKS- և ուղղակի արդյունքները տարբեր մշակում են պահանջում։ Պահպանեք դրանց նախապատվության կարգը և նախատեսված ձախողման քաղաքականությունը։
- Կարգավորեք սպառողին։ Տվեք ընտրված փրոքսի տեսակը, վերջնակետը և նույնականացման կարգավորումը դրանք աջակցող տրանսպորտի։ Հում TCP սոկետը վերադարձված URI-ից չի ստանում CONNECT կամ SOCKS բանակցություն։
Չպահեք մեկ պատասխան որպես բոլոր նպատակակետերի երթուղի և ուղղակի երթուղավորումը մշտական չդարձրեք միայն այն պատճառով, որ առաջին փրոքսին մեկ անգամ ձախողվել է։
Եթե HTTP հաճախորդն արդեն ինտեգրում է համակարգային փրոքսի կամ PAC հայտնաբերում, ընտրեք ընտրության մեկ սեփականատեր։ Երկու անկախ ընտրիչ և ևս մեկ փաթաթան կարող են ստեղծել երթուղի, որը ոչ մի քաղաքականություն չէր նախատեսել։
Տեղական կոդում հետևեք տեղադրված API-ի գործարանի և արդյունքների հիշողության կյանքի ցիկլին։ Գործարանի վերօգտագործումը կարող է պահպանել օգտակար հայտնաբերման վիճակ, սակայն այն դեռ պահանջում է հարցում յուրաքանչյուր նպատակակետի համար։ Գրանցեք ընտրությունը կապի արդյունքից առանձին. վերադարձված URI-ն չի ապացուցում հաջող նույնականացում, լուծում կամ հետագա հասանելիություն։