Не зовсім так: це залежить від налаштування клієнта. Давайте використаємо IE як основний приклад.
Якщо ви налаштовуєте IE з явним проксі-сервером: наприклад, не встановлені інші параметри, проксі встановлено на щось: 8080.
Користувач вводить адресу
IE перевіряє адресу на відповідність рядка на список виключень проксі-серверів IE (тобто "Обхід проксі для цих адрес:")
а. Якщо він збігається з записом в обхідному списку , то клієнт використовує свій власний DNS для дозволу імені, а потім клієнт підключається безпосередньо до цільових IP - адресою на порт 80 (передбачається), потім надсилає запит , як:
GET /something.htm HTTP/1.1
Host: fulldomainame.example.com
б. Якщо жоден запис обхідного списку не збігається , продовжуйте:
IE підключається до налаштованого проксі-сервера та надсилає запит форми:
GET http://fulldomainname.example.com/something.htm HTTP/1.1
Фактичний бонус: використання FQDN у URL-адресі - це один із способів сказати, що клієнт думає, що спілкується з проксі-сервером замість реального веб-сервера
Проксі-сервер вирішує це ім'я хоста за допомогою власного DNS, а потім підключається до цільового сайту (діє як клієнт у кроці 2 вище) тощо, тощо.
Під час використання WPAD / PAC:
У випадку використання сценарію веб-проксі автоматичного відкриття (WPAD) або автоматичного налаштування проксі-сервера (PAC або Autoconfig), наприклад, таких, які надаються ISA / TMG, коли автоконфігурація включена, це відрізняється:
Користувач вводить адресу
Клієнт завантажує поточний файл wpad.dat / autoproxy.js / .pac зі свого налаштованого місця
Клієнт шукає функцію " FindProxyForUrl " у файлі js та виконує її
Сценарій автопроксі обробляє ім'я хоста та URL-адресу . Це файл JavaScript з обмеженою функцією, але все ще можливо:
а. це може включати роздільну здатність імен (IsInNet, DnsResolve)
б. це може включати відповідність рядків (ShExpMatch)
c. це може включати підрахунок до мільйона (i ++)
г. це може включати в себе спливаючі повідомлення з наркісним сповіщенням, якщо адміністратор ривок
- (або просто смішно)
- ((або налагодження))
Функція FindProxyForUrl повертає щонайменше одну рядок : упорядкований список найкращих проксі для використання (розділено крапкою з комою)
а. або "DIRECT" , і в такому випадку клієнту необхідно вирішити саме ім'я та підключитися безпосередньо, відповідно до вищевказаного випадку
б. або "PROXY проксі-ім'я: 8080" або подібне; в цьому випадку клієнт підключається до цього порту на цьому проксі, повідомляє йому GET повну URL-адресу , а проксі виконує дозвіл імені .
- Як приклад : якщо функція сценарію повернула "PROXY yourProxy: 8080; DIRECT", який вказує клієнту підключитися до вашого проксі на порту TCP 8080, щоб запросити цю URL-адресу, і якщо це з'єднання неможливо встановити, спробуйте перейти безпосередньо.
Зауважте, що збій налаштування сеансу TCP не дуже швидкий, тому це, мабуть, не буде приємним відмовою для користувача, але нічого не б'є. Можливо.
Іноді трапляються збої, тонкощі та незрозумілі форми поведінки, але здебільшого, коли речі не ламаються дивними та цікавими способами, вище, як я бачив, це працює протягом багатьох років. Нові веб-переглядачі оптимізують поведінку, паралелізують речі та постійно пробують цікаві речі, тому перегляньте найсвіжіші документи для вашого браузера, щоб зрозуміти дрібницю.
Клієнт брандмауера WinSock / клієнт ISA / Клієнт TMG :
Якщо вас цікавить проксі-клієнт Winsock (з сервера TMG / ISA), це вже інша історія, яка має більшу гнучкість та рухомість деталей. Занадто багато, щоб зайти сюди, але є документи, навколо яких описано, як це працює. Коротше кажучи: він підключається до розеток Windows і може перехоплювати як запити на вирішення трафіку, так і розв’язання імен на основі TCP / UDP, на основі програми та користувача. Дуже потужний, але також застарілий зараз і не оновлювався протягом декількох років.
Клієнти можуть бути дійсно чіпкими:
Одне останнє зауваження : Після того, як клієнт HTTP вирішив поговорити з проксі для даного сайту / URL, немає ніякого способу для проксі сказати це не .
Немає коду або заголовка статусу HTTP для "Я не обслуговую це, вам слід просто перейти безпосередньо до нього" ...
Після того, як клієнт вирішить, що певна URL-адреса надається проксі-сервісом, настає зникнення проксі-смерті .
Єдиний спосіб уникнути цього - отримати логіку вибору безпосередньо перед тим, як клієнт здійснить з'єднання, у списку PAC або Bypass.
Остаточна примітка про файли зон та PAC
IE розглядає сайти, які підключені Прямо - навіть якщо вони мають точки в URL-адресі - бути частиною локальної інтранет-зони (за замовчуванням - встановити у властивостях Zone), і так буде робити такі дії, як дозволити інтегровану автентифікацію Windows на ці сайти (тобто Kerberos та / або автентифікація NTLM, прозоро). Таким чином, контроль того, чи є щось у локальній інтранет-зоні, визначає, наскільки йому довіряють з точки зору автоматичної аутентифікації. Знову ж, принаймні, за замовчуванням.