Виберіть метод входу через FTP-проксі, якого очікує ваш шлюз
Зіставте розмову USER, SITE або OPEN власного FTP-шлюзу з клієнтом, який її підтримує, тримаючи обліковий запис шлюзу окремо від цільового.
«FTP-проксі» може означати шлюз, який сам говорить FTP. Підключення до нього відрізняється від запиту CONNECT до HTTP-проксі або прохання до сервера SOCKS відкрити TCP-призначення.
Шлюзу потрібні цільовий хост і обліковий запис, і, можливо, спершу власний вхід. Продукти виражають цю розмову по-різному:
| Схема | Типова форма команди |
|---|---|
| Ціль закодована в імені користувача | USER target-user@target-host |
| Окремий вхід у шлюз | USER/PASS шлюзу, потім вхід у ціль |
| Явна команда призначення | SITE target-host або OPEN target-host, потім потрібний вхід |
Це родини угод, а не єдина стандартна послідовність для кожного шлюзу. Виберіть метод, задокументований адміністратором і підтримуваний клієнтом.
Тримайте обидва облікові записи видимими в налаштуванні
Пароль цільового FTP і пароль шлюзу можуть відрізнятися. Деякі шлюзи об'єднують їх в одне подання USER/PASS; інші вимагають окремих обмінів. Розміщення всіх значень в одному рядку не може відтворити клієнт, якому треба надсилати додаткові команди.
Це пояснює корисну межу в старому коді FtpWebRequest. Звичайне FTP-підключення до шлюзу, з іменем користувача, властивим шлюзу, може відповідати деяким схемам USER/PASS. Шлюз, що вимагає окремої розмови SITE або OPEN, потребує клієнта, який справді підтримує цей потік. Властивість Proxy у WebRequest — знову інший інтерфейс.
Наприклад, WinSCP пропонує окремі методи входу через FTP-проксі, а не розглядає всі шлюзи як одне поле хоста. Його числові значення сирих налаштувань належать до його задокументованого API; під час перевірки конфігурації використовуйте назву методу й передбачувану розмову.
Після входу передавання файлів усе ще потребує з'єднання даних FTP і вибраного режиму TLS. Успішний вхід каналом керування — початок цього шляху, а не доказ того, що будь-яке передавання даних уже дозволене.