Ang diksyunaryo ng proxy ng Requests ay hindi gumagawa ng kadena
Ihiwalay ang pagpili ng ruta at pag-ikot ng proxy ng Requests mula sa tunay na pagkakasunod-sunod ng mga paglundag ng proxy.
Ang mga entry na http at https sa diksyunaryo ng proxy ng Requests ay pumipili ng mga ruta para sa mga scheme ng destinasyon. Hindi nila ibig sabihin na “kumonekta sa unang proxy, pagkatapos sa pangalawa”.
Gayundin, ang isang loop na pumipili ng isang endpoint para sa bawat kahilingan ay nag-ikot ng mga proxy. Ginagamit pa rin ng bawat kahilingan ang piniling ruta. Ang isang array na may ilang address ay hindi gumagawa ng lagusan sa lahat ng ito.
Ang tunay na kadena ay nangangailangan ng connector o kaayusan ng upstream proxy na nagtatatag ng sunud-sunod na paglundag. Ang pagsasama ng proxy ng aplikasyon sa isang wrapper ng proseso ay isang posibleng nested na kaayusan, alinsunod sa mga limitasyon ng interception ng wrapper. Dapat suportahan ng bawat paglundag ang kinakailangang protocol, authentication at koneksyon sa destinasyon. Ang ordinaryong diksyunaryo ng proxy ng Requests ay hindi naglalarawan ng negosasyong iyon.
Isulat ang nilalayong landas bago pumili ng implementasyon. Para sa isang pinapayagang pampublikong pool, ang listahan ng libreng proxy ay nag-aalok ng mga kandidato na ang mga protocol ay dapat tugma sa piniling implementasyon. Ang fallback na listahan, rotation pool at kadena ay lumulutas ng iba't ibang problema sa routing, kahit na ang tatlo ay nagsisimula sa parehong listahan ng mga address ng IP.