So, hätte gern schon früher ein Update gepostet - aber konnte mich nicht registrieren.

Also: Ja, ich bin bezüglich des Proxychains fündig geworden ->
LWP::Protocol::http::SocksChain <- von Igor Okunev. Ist eine "Erweiterung" von Net-SC und erledigt das ganze Proxy-Kaskading fast von selbst.

Um das "X_Forwarded_for" field im HTTP Header zu *manipulieren* genügt HTTP::Headers (header, push_header,remove_header). Das selbe funktioniert natürlich auch für andere Prroxy-  relevante Felder wie "Via". Natürlich könnt ihr aber auch einen eigenen Proxy Server dazwischen Schalten und dort die Header manipulieren.

Der X_Fwd.Tag wird auch von transparenten Proxy-servern unterschiedlich gehandhabt. In der Regel wird wie erwartet der Tag durchgereicht. Hier kann man mit der Header-Manipulation ansetzen:

$h = HTTP::Headers->new;
$h->header( MIME_Version =>'1.0',User_Agent   =>  $browser,VIA => $via,X_Forwarded_for => $x_forwarded_for,Referer => $referer);
$request_ad = HTTP::Request->new('GET', $adlink, $h);

In der Regel zeigt der letzte Proxy in der Kette dann die "manipulierte" Ip als X_Fwd_for: an -> aber Vorsicht -> einige Proxies verstehen den Tag als Listenfeld und hängen jeden Proxy-Hopp seperat ans Feld an oder extrahieren die Source-IP des Requestes etwas genauer.  

Beipiel:
Firefox -> trans.Proxy -> ipchecker.com
(ip checker zeigt x_fwd_for: meine IP)

Perl Skript + manipulierter Header -> Proxy -> ipchecker.com
(ip checker zeigt x_fwd_for: manipulierte IP, meine IP)

Es gibt übrigens auch Tr-Proxies - die sich eher wie anonyme verhalten und in der Regel kein X_Fwd_for Feld weitergeben -> sich aber völlig anderes verhalten sobald ihr einen eingenen *manipulierten* Header verwendet. Sie geben dann den X_Forw_Tag weiter, da sie meinen, dass vor ihnen nur ein weitere Proxy hängt.

Beipiel:
Firefox -> trans.Proxy -> ipchecker.com
(ip checker zeigt x_fwd_for: *nichts*)

Perl Skript + manipulierter Header -> trans. Proxy -> ipchecker.com
(ip checker zeigt x_fwd_for: manipulierte IP)

Dass ist natürlich manchmal unnötig -> da der IPChecker dann weiß, dass ihr von einem Proxy kommt. Hättet ihr den Header nicht gesendet meint der ipchecker, dass die "Trans"-Proxy-IP eine tatsächliche Client Adresse ist.

Fazit: Ihr solltet bevor ihr soetwas nutzt immer gegen eine ipcheck Website prüfen - bevor ihr das reale Ziel abruft. Dabei aber das Via und X_Forwarded_for Feld weglassen oder über remove_header entfernen. Taucht dann bei Check eure Client-IP auf -> seit ihr eben nicht anonym und ihr prüft selbiges nocheinmal mit gefakten Header-Feldern. Möglicherweise taucht jetzt eure IP beim IPChecker nicht mehr auf, sondenr nur die Faked IP.  

Werden die relevanten Felder von vornherein als *leer* angezeigt, dann seit ihr anonym und es ist unnötigt den Header zu manipulieren, da ihr zwar auch dann anonym mit gefakter IP seit -> aber eben manchmal unnötigerweise die Proxy-IP eben als "Proxy"-IP entarnt werden kann. Manchmal ist es eben sinnvoll, wenn der Remote Server nicht weiß, dass ihr über einen Proxy kommt.

Nun, sei's drum. Natürlich kann man das ganze Dilema auch umschiefen indem man von Anfang an auf Anonyme Proxies setzt -> aber auch hier solltet ihr eben im Einzelfall prüfen ob ihr wirklich anonym seit und des weiteren sind für manche Vorhaben die erhältichen Anonymen-Proxy-Listen leider unzureichend ...

Wofür dies auch immer zu grbrauchen sein mag -> denkt an das Proxychain Modul! Dann kann auch nicht mehr viel schiefgehen.