Ці можа PHP cURL выкарыстоўваць IP наведвальніка?
Растлумачце, якая машына адкрывае cURL-злучэнне на баку сервера і што трэба праксі, каб змяніць гэты маршрут.
Наведвальнік націскае кнопку. Ваш PHP-сервер выклікае знешні API. API бачыць зыходнае злучэнне сервера або выхад праксі, наладжанага для гэтага злучэння. Браўзер наведвальніка трымае асобнае злучэнне з вашым сайтам.
Капіраванне адраса наведвальніка ў загаловак не можа перанесці PHP-злучэнне ў сетку наведвальніка. Загалоўкі — гэта даныя, якія перадаюцца праз ужо ўсталяванае злучэнне. Прызначэнне можа выкарыстоўваць давераны загаловак перасылкі ў сваёй логіцы, але гэта не робіць значэнне загалоўка адрасам крыніцы злучэння.
Праксі павінна прыняць злучэнне
Каб адправіць PHP cURL праз іншую машыну, гэтая машына павінна прапаноўваць дасяжную праксі-службу з дазволам пераносіць запыт. PHP-працэс павінен мець магчымасць да яе падключыцца. Звычайная браўзерная сесія наведвальніка не дае вашаму серверу такога праксі-энда.
Опцыя праксі libcurl выбірае службу, да якой падключаецца cURL. Яна не можа папрасіць адвольны браўзер сфарміраваць запыт ад свайго імя.
Запыт браўзера — іншая архітэктура
Для некаторых API браўзер можа выклікаць прызначэнне напрамую. Гэта змяшчае запыт на сеткавы шлях карыстальніка, з улікам яго ўласнай праксі-канфігурацыі. Гэта таксама патрабуе API, распрацаванага для браўзерных кліентаў. Міжкрынічны доступ падпарадкоўваецца CORS, а ўліковыя даныя, адпраўленыя ў браўзерны код, становяцца даступнымі гэтаму кліенту.
Вызначце, дзе павінен знаходзіцца запыт, перш чым выбіраць опцыю праксі. Трымайце серверныя ўліковыя даныя на серверы; выкарыстоўвайце дакументаваную браўзерную інтэграцыю, калі служба яе падтрымлівае. Ні адна з архітэктур не прапаноўвае надзейнага скароту, каб серверны запыт атрымаў у спадчыну сеткавую ідэнтычнасць наведвальніка.