libproxy izvēlas maršrutu; savienojumu izveido jūsu klients

Izmantojiet libproxy rezultātus kā maršrutēšanas kandidātus katram URL, nevis gaidiet, ka atklāšana pārvirzīs lietojumprogrammas ligzdas.

Ja libproxy atgriež starpniekservera URI, bet nākamā ligzda savienojas tieši, pārbaudiet nodošanu. libproxy atklāj politiku; tas neuzķer katru ligzdu, ko atver lietojumprogramma.

  1. Vaicājiet resursu. Dokumentētajā libproxy 0.5 C API izveidojiet starpniekservera rūpnīcu un pieprasiet faktisko galamērķa URL.
  2. Interpretējiet sakārtotos kandidātus. HTTP, SOCKS un tiešajiem rezultātiem nepieciešama atšķirīga apstrāde. Saglabājiet to prioritātes secību un paredzēto atteices politiku.
  3. Konfigurējiet patērētāju. Nododiet izvēlēto starpniekservera tipu, galapunktu un autentifikācijas kārtību transportam, kas tos atbalsta. Neapstrādāta TCP ligzda no atgrieztā URI neiegūst CONNECT vai SOCKS sarunas.

Neglabājiet vienu atbildi kā maršrutu visiem galamērķiem un nepadariet tiešo maršrutēšanu pastāvīgu tikai tāpēc, ka pirmais starpniekserveris vienreiz neizdevās.

Ja HTTP klients jau integrē sistēmas starpniekserveri vai PAC atklāšanu, izvēlieties vienu atlases īpašnieku. Divi neatkarīgi atlasītāji un vēl viens ietvars var radīt maršrutu, ko nebija paredzējusi neviena politika.

Vietējā kodā ievērojiet instalētā API rūpnīcas un rezultātu atmiņas dzīves ciklu. Rūpnīcas atkārtota izmantošana var saglabāt noderīgu atklāšanas stāvokli, taču tai joprojām nepieciešams vaicājums katram galamērķim. Reģistrējiet atlasi atsevišķi no savienojuma rezultāta: atgrieztais URI nepierāda veiksmīgu autentifikāciju, atrisinājumu vai turpmāku piekļuvi.

Saistītie raksti