libproxy memilih rute; klien Anda membuat koneksi
Gunakan hasil libproxy sebagai kandidat perutean per URL alih-alih mengharapkan penemuan mengalihkan soket aplikasi.
Jika libproxy mengembalikan URI proksi sementara soket berikutnya terhubung langsung, periksa penyerahannya. libproxy menemukan kebijakan; ia tidak menyadap setiap soket yang dibuka aplikasi.
- Tanyakan sumber daya. Dalam API C libproxy 0.5 yang terdokumentasi, buat pabrik proksi dan mintalah URL tujuan sebenarnya.
- Tafsirkan kandidat yang berurutan. Hasil HTTP, SOCKS, dan langsung memerlukan penanganan berbeda. Pertahankan urutan preferensi dan kebijakan kegagalan yang dimaksud.
- Konfigurasikan konsumen. Berikan jenis proksi terpilih, titik akhir, dan pengaturan autentikasi kepada transport yang mendukungnya. Soket TCP mentah tidak memperoleh negosiasi CONNECT atau SOCKS dari URI yang dikembalikan.
Jangan simpan satu jawaban sebagai rute untuk semua tujuan atau menjadikan perutean langsung permanen karena proksi pertama pernah gagal sekali.
Jika klien HTTP sudah mengintegrasikan proksi sistem atau penemuan PAC, pilih satu pemilik pemilihan. Dua pemilih independen ditambah pembungkus lain dapat menghasilkan rute yang tidak diniatkan oleh kedua kebijakan.
Dalam kode native, ikuti siklus hidup pabrik dan memori hasil API yang terpasang. Menggunakan ulang pabrik dapat mempertahankan status penemuan yang berguna, tetapi tetap memerlukan kueri untuk setiap tujuan. Catat pemilihan secara terpisah dari hasil koneksi: URI yang dikembalikan tidak membuktikan autentikasi, resolusi, atau akses lanjutan yang berhasil.