Какие данные собрать перед обращением в поддержку прокси: пошаговый гайд

Фраза "не работает прокси" для инженера поддержки звучит примерно как "болит где-то внутри" для врача. Направление понятно, но без анализов и симптомов диагноз поставить нельзя. В этом гайде вы научитесь собирать ровно тот набор данных, который превращает расплывчатую жалобу в конкретную задачу с одним понятным ответом.

Введение: почему "не работает" невозможно диагностировать

Представьте два обращения в поддержку Proxeon. Первое: "Купил прокси, ничего не работает, помогите". Второе: "Прокси с идентификатором PX-48213 в 14:32 по МСК (UTC+3) отдаёт ошибку соединения при запросе к api.example.com через HTTP, при этом к другому сайту тот же прокси работает, прямое соединение без прокси тоже работает, вывод curl прилагаю". Первое обращение запускает цепочку из пяти-шести уточняющих писем, каждое из которых занимает часы ожидания. Второе закрывается одним ответом.

Разница не в вежливости и не в удаче. Разница в данных. Инженер не видит ваш экран, не знает вашу операционную систему, не может воспроизвести ваш запрос без исходных параметров. Всё, что у него есть, — текст вашего письма. Если в этом тексте нет фактов, первое, что он сделает, — запросит факты. Это и есть та самая цепочка писем, которая растягивает решение простой проблемы на несколько дней.

Что получит читатель в итоге

После этого руководства вы сможете за 15-20 минут собрать пакет диагностики, который содержит всё необходимое для решения проблемы с первого ответа. У вас будет готовый скрипт, который соберёт технические данные в один текстовый файл, шаблон обращения для копирования и чёткое понимание, какие проверки нужно выполнить до того, как писать в поддержку.

Для кого этот гайд

Руководство рассчитано на пользователей прокси среднего уровня: тех, кто умеет открыть терминал или командную строку, знает, что такое URL, и настраивал прокси в приложении хотя бы раз. Продвинутые пользователи найдут здесь готовый скрипт диагностики и таблицу изоляции проблемы. Начинающим мы подробно объясним каждый термин.

Что нужно знать заранее

Достаточно понимать три вещи. Прокси — это посредник, через который идёт ваш сетевой запрос. Целевой адрес — сайт или сервис, к которому вы обращаетесь. Клиент — программа, которая делает запрос через прокси (браузер, парсер, скрипт). Всё остальное разберём по ходу.

Сколько времени потребуется

Первое прохождение по гайду с настройкой скрипта займёт около 30 минут. Дальше сбор диагностики по готовому шаблону будет отнимать 10-15 минут. Это несопоставимо меньше, чем несколько дней переписки с уточнениями.

Совет: сохраните этот гайд и скрипт в закладки. Проблемы с прокси возникают редко, и когда они появляются, вспомнить всю процедуру заново трудно. Готовый чек-лист под рукой экономит нервы.

Предварительная подготовка: инструменты и доступы

Прежде чем собирать данные, убедитесь, что у вас есть базовые инструменты. Все они бесплатны и в большинстве систем уже установлены.

Необходимые инструменты

• curl — утилита командной строки для отправки сетевых запросов. Это наш главный инструмент воспроизведения проблемы. В macOS и большинстве дистрибутивов Linux она предустановлена. В Windows 10 и 11 она также входит в состав системы.
• Терминал или командная строка — окно, где вы вводите команды. В Windows это PowerShell или Командная строка (cmd), в macOS и Linux — Terminal.
• Текстовый редактор — Блокнот, TextEdit или любой другой для просмотра собранного файла и удаления секретов.
• Данные вашего прокси от Proxeon — идентификатор, адрес, порт, логин и пароль. Они выданы вам в личном кабинете.

Проверка наличия curl

Откройте терминал и выполните простую проверку.

1. В Windows нажмите клавишу Win, наберите PowerShell и откройте приложение.
2. В macOS откройте Spotlight сочетанием Cmd+Пробел, наберите Terminal и нажмите Enter.
3. В Linux откройте терминал через меню приложений или сочетанием Ctrl+Alt+T.
4. Введите команду

   curl --version

   и нажмите Enter.

Если вы увидите строку вида "curl 8.x.x" с перечнем поддерживаемых протоколов, инструмент готов. Если система пишет, что команда не найдена, установите curl: в Windows обновите систему до актуальной версии, в Linux выполните установку через пакетный менеджер вашего дистрибутива.

✅ Проверка: команда

curl --version

Что подготовить из данных Proxeon

Зайдите в личный кабинет Proxeon на proxeon.net и откройте карточку вашего прокси. Выпишите или скопируйте в отдельный файл следующие поля: идентификатор прокси, хост (адрес), порт, тип (HTTP, HTTPS или SOCKS5), логин и пароль. Эти данные понадобятся для формирования команды воспроизведения.

⚠️ Внимание: логин и пароль от прокси — это секретные данные. Мы будем работать с ними локально, но в обращение в поддержку их вставлять НЕ нужно. Ниже есть отдельный раздел о том, как безопасно чистить логи перед отправкой.

Базовые понятия: граница клиент — прокси — сервер

Чтобы понимать, какие данные важны, нужно представлять путь запроса. Он проходит три участка, и проблема может возникнуть на любом из них.

Три звена одной цепи

Когда вы обращаетесь к сайту через прокси, запрос идёт так: ваш клиент отправляет запрос на прокси-сервер, тот перенаправляет его на целевой сервер, получает ответ и возвращает вам. Три звена, две границы. Понимание того, на какой границе застряло, — это и есть половина диагностики.

• Граница клиент — прокси. Если запрос не дошёл даже до прокси, проблема на вашей стороне: неверный адрес прокси, закрытый порт, корпоративный фильтр, ошибка в настройках клиента.
• Граница прокси — сервер. Если прокси принял запрос, но не смог достучаться до целевого сайта, проблема между прокси и целью: сайт недоступен, отвергает соединение или отвечает ошибкой.

Задача диагностики — определить, на какой границе всё сломалось. Инженер поддержки Proxeon по вашему выводу сразу увидит, где остановился запрос, и это резко сузит круг причин.

Почему точное время так важно

Прокси-инфраструктура ведёт логи. Чтобы найти в них ваш конкретный запрос, инженеру нужно точное время события с указанием часового пояса. "Сегодня утром" в логах не ищется. "14:32 по МСК, UTC+3" ищется за секунды. Разница во времени между вашей формулировкой и записью в логе — частая причина того, что событие вообще не находят.

Совет: всегда указывайте часовой пояс явно. Формат "UTC+3" или "МСК" понятен без домыслов. Если вы в другом поясе, укажите свой — сервер сам пересчитает.

Шаг 1: Собрать минимальный набор данных

Цель этапа: зафиксировать пять фактов, без которых любое обращение будет неполным. Это фундамент, всё остальное надстраивается сверху.

Пять обязательных фактов

1. Идентификатор прокси. Точное имя или номер из личного кабинета Proxeon, например PX-48213. Не "тот прокси, что купил вчера", а конкретный идентификатор. Если у вас пакет из нескольких прокси, укажите, о каком именно идёт речь.
2. Точное время с часовым поясом. Когда именно возникла проблема. Формат: дата, время, пояс. Например: 12 марта 2026, 14:32, UTC+3. Если проблема повторяется, укажите несколько временных меток.
3. Целевой адрес. Полный URL или хост, к которому вы обращались. Например: https://api.example.com/v2/data. Не "один сайт", а точный адрес.
4. Что именно вы делали. Одно-два предложения о действии. "Отправлял GET-запрос из своего скрипта" или "открывал сайт в браузере с настроенным прокси". Контекст помогает понять природу запроса.
5. Что вы ожидали и что получили. Ожидали код 200 и данные, получили ошибку соединения. Ожидали загрузку страницы, получили бесконечную загрузку. Разница между ожиданием и реальностью — суть проблемы.

⚠️ Внимание: не заменяйте конкретику эмоциями. "Всё тормозит и вообще ужас" не несёт технической информации. "Ответ приходит за 40 секунд вместо обычных 2" — несёт.

Как зафиксировать время правильно

Если проблема происходит прямо сейчас, посмотрите на часы и запишите время немедленно. Если она была в прошлом, восстановите время по логам вашего приложения или по истории браузера. Чем точнее метка, тем быстрее найдётся запись на стороне сервера.

✅ Проверка: у вас есть пять записанных фактов. Прочитайте их вслух. Если человек, не видящий ваш экран, понимает, что произошло, где и когда, — минимальный набор собран.

Шаг 2: Воспроизвести проблему одной командой curl

Цель этапа: свести проблему к единственной команде, которую инженер сможет мысленно или буквально повторить, и получить подробный технический вывод.

Браузер и сложный скрипт делают десятки скрытых действий. Изолировать проблему в них трудно. Утилита curl делает ровно один запрос и показывает каждый его этап. Это идеальный инструмент воспроизведения.

Базовая команда через прокси Proxeon

Соберите команду из ваших данных. Общий вид такой:

curl -v -x http://ЛОГИН:ПАРОЛЬ@ХОСТ:ПОРТ https://ЦЕЛЕВОЙ-АДРЕС

Разберём флаги. -v включает подробный режим (verbose): curl покажет весь ход соединения построчно. -x задаёт прокси, через который идёт запрос. После него — адрес прокси с авторизацией. В конце — целевой адрес.

Пример с подставленными значениями (данные вымышленные):

curl -v -x http://user123:secretpass@proxy.proxeon.net:8080 https://api.example.com/v2/data

Добавляем измерение времени и запись в файл

Чтобы вывод был максимально информативным, расширим команду. Флаг -w добавит сводку по таймингам в конце.

curl -v -x http://user123:secretpass@proxy.proxeon.net:8080 -w "Итоговый код: %{http_code}, общее время: %{time_total}s" https://api.example.com/v2/data

Теперь в самом конце вывода вы увидите итоговый HTTP-код и общее время запроса. Это ключевые цифры для диагностики скорости.

Совет: если проблема в медленной работе, а не в ошибке, добавьте детальные тайминги через

-w "dns: %{time_namelookup} connect: %{time_connect} start: %{time_starttransfer} total: %{time_total}"

Для SOCKS5-прокси

Если ваш прокси типа SOCKS5, поменяйте схему в адресе:

curl -v -x socks5://user123:secretpass@proxy.proxeon.net:1080 https://api.example.com/v2/data

⚠️ Внимание: команда содержит ваш реальный логин и пароль. Выполняйте её в своём терминале, но НЕ копируйте её с секретами в письмо. В обращении логин и пароль заменяются заглушками — об этом в шаге 5.

Порядок выполнения

1. Откройте терминал.
2. Вставьте собранную команду, подставив свои реальные данные.
3. Нажмите Enter и дождитесь завершения.
4. Выделите весь вывод от первой строки до последней и скопируйте его в текстовый файл.

✅ Проверка: вы получили многострочный вывод, где видны строки, начинающиеся с символов "*", ">" и "<". Если вывод есть, воспроизведение удалось, даже если запрос завершился ошибкой — ошибка тоже ценная информация.

Шаг 3: Прочитать вывод построчно и найти границу проблемы

Цель этапа: научиться понимать, что показывает вывод curl, и определять, на каком звене остановился запрос. Расшифровку конкретных кодов ошибок мы здесь не дублируем — для этого есть отдельная статья в базе знаний Proxeon, дайте на неё ссылку в обращении при необходимости.

Три типа строк в выводе

Подробный вывод curl использует префиксы, по которым легко ориентироваться.

• Строки со звёздочкой (*) — служебные сообщения самого curl о ходе соединения: разрешение имени, установка связи с прокси, рукопожатие шифрования. Это внутренняя кухня.
• Строки со стрелкой вправо (>) — это то, что ваш клиент ОТПРАВЛЯЕТ. Заголовки запроса, метод, путь.
• Строки со стрелкой влево (<) — это то, что вам ОТВЕЧАЮТ. Код ответа, заголовки сервера.

Где проходит граница клиент — прокси

В начале вывода curl сообщает, что устанавливает соединение с прокси. Вы увидите строку вида "Connected to proxy.proxeon.net port 8080". Если этой строки нет, а вместо неё ошибка соединения, значит запрос не дошёл до прокси. Проблема на границе клиент — прокси: возможно, закрыт порт, неверный адрес или мешает локальный фильтр.

Если строка о подключении к прокси есть, но дальше идёт ошибка авторизации, значит прокси доступен, но не принял ваш логин и пароль. Это тоже граница клиент — прокси, но уже уровень аутентификации.

Где проходит граница прокси — сервер

После успешного подключения к прокси curl показывает установку соединения с целевым сервером через прокси. Если здесь возникает ошибка, значит прокси принял запрос, но не смог достучаться до цели. Проблема на границе прокси — сервер: целевой сайт недоступен, отвергает соединение или медленно отвечает.

Если же вы видите строку ответа со стрелкой влево, например "< HTTP/1.1 200" или другой код, значит вся цепочка отработала и вы получили ответ. Дальше уже вопрос содержания ответа, а не работы прокси.

Ключевые строки, которые важны инженеру

1. Строка подключения к прокси — подтверждает, что первое звено работает.
2. Строка об авторизации на прокси — показывает, приняты ли учётные данные.
3. Строка о рукопожатии шифрования (TLS) — важна для HTTPS-целей.
4. Первая строка ответа со стрелкой влево — итоговый вердикт цепочки.
5. Итоговая сводка с кодом и временем из флага -w.

Совет: не пытайтесь самостоятельно ставить диагноз по коду ошибки, если не уверены. Ваша задача — приложить полный вывод. Инженер Proxeon прочитает его точнее. Полная расшифровка кодов есть в отдельной статье базы знаний — сошлитесь на неё, если хотите разобраться глубже.

✅ Проверка: вы можете указать пальцем строку, после которой запрос сломался, и сказать, на какой это границе — клиент-прокси или прокси-сервер. Если можете, вы прошли этот этап.

Шаг 4: Выполнить проверки до обращения

Цель этапа: методом исключения сузить круг причин ещё до того, как вы напишете в поддержку. Каждая проверка отсекает целый класс проблем.

Принцип прост: меняем один параметр за раз и смотрим, изменилось ли поведение. Это классический инженерный подход к изоляции неисправности.

Четыре ключевые проверки

1. Другой целевой сайт. Повторите тот же запрос через тот же прокси, но к другому адресу. Возьмите заведомо стабильный публичный сайт. Если к нему прокси работает, а к вашей цели нет, проблема связана с целевым сайтом или его отношением к прокси, а не с самим прокси.
2. Другой протокол. Если использовали HTTP, попробуйте HTTPS-цель, и наоборот. Иногда проблема проявляется только на одном протоколе, и это важный сигнал.
3. Другой прокси. Если у вас есть второй прокси от Proxeon, повторите запрос через него. Если второй работает, а первый нет — проблема в конкретном прокси. Если оба ведут себя одинаково — проблема системнее.
4. Прямое соединение. Выполните запрос к цели БЕЗ прокси, напрямую. Уберите флаг -x. Если напрямую сайт тоже недоступен, проблема не в прокси вовсе, а в самом целевом сайте или вашей сети.

Команда для прямой проверки

curl -v https://api.example.com/v2/data

Та же команда, но без части с прокси. Сравните результат с запросом через прокси.

Таблица: что исключает каждая проверка

Ниже — как трактовать результаты проверок.

• Другой сайт работает, ваш нет. Исключает поломку прокси в целом. Указывает на специфику взаимодействия конкретной цели с прокси.
• Другой протокол работает, ваш нет. Исключает полную недоступность. Локализует проблему на уровне конкретного протокола или порта.
• Другой прокси работает, ваш нет. Исключает проблему на вашей стороне и в сети. Указывает на конкретный прокси.
• Прямое соединение не работает тоже. Исключает вину прокси. Проблема в целевом сайте или вашей сети.
• Прямое работает, через прокси нет. Подтверждает, что дело именно в связке с прокси, и это как раз то, с чем поможет поддержка.

Совет: результаты этих четырёх проверок — самая ценная часть обращения. Они экономят инженеру половину работы, потому что вы уже отсекли лишнее. Обязательно перечислите их в письме.

⚠️ Внимание: используйте эти прокси исключительно для законных задач: тестирование своих сервисов, сбор публичных данных в рамках правил, работа с API. Проверки не предназначены для действий, нарушающих правила сайтов или законодательство.

✅ Проверка: у вас есть результаты по всем четырём проверкам, и вы можете одной фразой сказать, что они в совокупности исключают. Например: "прямое соединение и другой прокси работают, значит дело в конкретном прокси PX-48213 при обращении к этой цели".

Шаг 5: Собрать данные о своей стороне

Цель этапа: описать окружение, в котором возникает проблема. Половина непонятных случаев объясняется особенностями клиента или локальной сети.

Что указать об окружении

1. Операционная система и её версия. Windows 11, macOS 15, Ubuntu 24.04. Точная версия помогает воспроизвести условия.
2. Клиент и его версия. Через что вы работаете с прокси: браузер и его версия, название и версия парсера или библиотеки, версия curl. Разные клиенты по-разному обрабатывают прокси.
3. Способ настройки прокси. Настроен в системе, в браузере, передаётся в коде, задан в переменных окружения. Это влияет на то, как именно применяется прокси.
4. Наличие корпоративного или локального фильтра. Работаете ли вы из корпоративной сети, есть ли антивирус с сетевым экраном, стоит ли локальный файрвол. Такие фильтры могут перехватывать или блокировать соединения ещё до прокси.
5. Тип подключения к интернету. Домашний провайдер, мобильный интернет, рабочая сеть. Иногда провайдер влияет на доступность.

Как узнать версию клиента

Для curl используйте уже знакомую команду

curl --version

Проверка корпоративного фильтра

Если вы в корпоративной сети и подозреваете фильтр, это легко проверить. Выполните запрос напрямую к прокси без цели и посмотрите, устанавливается ли соединение. Если даже прямое подключение к порту прокси не проходит, а из другой сети проходит, вероятен корпоративный фильтр на исходящие соединения.

Совет: корпоративные сети часто разрешают только порты 80 и 443. Если ваш прокси на нестандартном порту, узнайте у своего сетевого администратора, открыт ли этот порт наружу. Это частая и легко решаемая причина.

✅ Проверка: у вас есть заполненный список из пяти пунктов об окружении. Инженер, прочитав его, знает, в каких условиях воспроизводить проблему.

Шаг 6: Автоматизировать сбор диагностики одним скриптом

Цель этапа: собрать всю техническую информацию в один текстовый файл, не переписывая её вручную. Скрипт делает то же, что вы делали руками, но за один запуск.

Скрипт для macOS и Linux

Создайте файл diag.sh со следующим содержимым. Замените значения переменных на свои.

#!/bin/bash
PROXY="http://ЛОГИН:ПАРОЛЬ@ХОСТ:ПОРТ"
TARGET="https://ЦЕЛЕВОЙ-АДРЕС"
ALT="https://СТАБИЛЬНЫЙ-САЙТ"
OUT="diag_result.txt"
echo "=== Дата и время ===" > $OUT
date >> $OUT
echo "=== Версия curl ===" >> $OUT
curl --version >> $OUT 2>&1
echo "=== Запрос через прокси к цели ===" >> $OUT
curl -v -x $PROXY -w "code:%{http_code} total:%{time_total}s" $TARGET >> $OUT 2>&1
echo "=== Запрос через прокси к альтернативному сайту ===" >> $OUT
curl -v -x $PROXY -w "code:%{http_code} total:%{time_total}s" $ALT >> $OUT 2>&1
echo "=== Прямой запрос к цели без прокси ===" >> $OUT
curl -v -w "code:%{http_code} total:%{time_total}s" $TARGET >> $OUT 2>&1
echo "Готово. Файл: $OUT"

Как запустить скрипт

1. Сохраните файл под именем diag.sh.
2. Впишите свои значения в переменные PROXY, TARGET и ALT.
3. В терминале перейдите в папку с файлом.
4. Сделайте файл исполняемым командой

   chmod +x diag.sh

5. Запустите его командой

   ./diag.sh

6. После завершения откройте файл diag_result.txt.

Скрипт для Windows (PowerShell)

Создайте файл diag.ps1 с аналогичной логикой.

$Proxy = "http://ЛОГИН:ПАРОЛЬ@ХОСТ:ПОРТ"
$Target = "https://ЦЕЛЕВОЙ-АДРЕС"
$Alt = "https://СТАБИЛЬНЫЙ-САЙТ"
$Out = "diag_result.txt"
"=== Дата и время ===" | Out-File $Out
Get-Date | Out-File $Out -Append
"=== Версия curl ===" | Out-File $Out -Append
curl --version 2>&1 | Out-File $Out -Append
"=== Через прокси к цели ===" | Out-File $Out -Append
curl -v -x $Proxy -w "code:%{http_code} total:%{time_total}s" $Target 2>&1 | Out-File $Out -Append
"=== Через прокси к альтернативе ===" | Out-File $Out -Append
curl -v -x $Proxy $Alt 2>&1 | Out-File $Out -Append
"=== Прямой запрос ===" | Out-File $Out -Append
curl -v $Target 2>&1 | Out-File $Out -Append

Запустите его в PowerShell командой

.\diag.ps1

⚠️ Внимание: файл diag_result.txt содержит ваши логин и пароль в открытом виде, потому что они были в переменной PROXY. Перед отправкой в поддержку ОБЯЗАТЕЛЬНО очистите его по инструкции из шага 7.

Совет: храните скрипт с пустыми переменными, а значения вставляйте только перед запуском. Так вы не рискуете случайно поделиться файлом с секретами внутри.

✅ Проверка: файл diag_result.txt создан и содержит несколько блоков: версию curl, запросы через прокси к двум сайтам и прямой запрос. Это готовый пакет технической диагностики.

Шаг 7: Безопасно очистить логи перед отправкой

Цель этапа: удалить из собранных данных всё секретное, сохранив при этом их диагностическую ценность. Отправлять логи с паролями нельзя ни в коем случае.

Что вырезать обязательно

• Пароль от прокси. В выводе он мог попасть в строку соединения. Найдите и замените.
• Логин, если он привязан к платёжным данным. Обычно логин можно оставить, но если это часть чувствительной связки, замените и его.
• Токены авторизации. Если в заголовках запроса есть Authorization, Bearer-токены, API-ключи, cookie сессии — всё это вырезать.
• Персональные данные. Любые имена, адреса, телефоны, если они случайно попали в тело запроса или ответа.

Чем заменять

Не удаляйте строку целиком — так теряется структура. Заменяйте секрет на понятную заглушку, сохраняя длину и формат по возможности. Примеры замен:

• Пароль замените на [ПАРОЛЬ_СКРЫТ].
• Логин на [ЛОГИН_СКРЫТ].
• Токен на [ТОКЕН_СКРЫТ].

Таким образом инженер видит, что в этом месте был токен, но не видит его значения. Структура сохранена, безопасность тоже.

Порядок очистки

1. Откройте файл diag_result.txt в текстовом редакторе.
2. Используйте поиск (Ctrl+F) по своему паролю и замените все вхождения на заглушку.
3. То же самое сделайте с логином, если решили его скрыть.
4. Просмотрите строки с заголовками Authorization, Cookie, api-key. Замените значения на заглушки.
5. Сохраните файл под новым именем, например diag_clean.txt, чтобы не перепутать с оригиналом.

⚠️ Внимание: проверьте файл дважды перед отправкой. Пароль мог встретиться не только в команде, но и в строках вывода curl. Пропущенный секрет — это утечка, которая может привести к компрометации вашего прокси.

Совет: держите оригинал diag_result.txt локально, а отправляйте только очищенную копию. Если инженер попросит уточнение, у вас под рукой полные данные.

✅ Проверка: откройте очищенный файл и выполните поиск по вашему паролю. Ноль результатов — значит очистка удалась. Структура вывода при этом сохранена.

Шаг 8: Заполнить готовый шаблон обращения

Цель этапа: собрать всё воедино в письмо, которое инженер прочитает и сразу поймёт задачу. Ниже — шаблон для копирования.

Шаблон обращения в поддержку Proxeon

Тема: Проблема с прокси [ИДЕНТИФИКАТОР] при обращении к [ЦЕЛЬ]

1. Идентификатор прокси: [например PX-48213]
2. Тип прокси: [HTTP / HTTPS / SOCKS5]
3. Время проблемы: [12.03.2026, 14:32, UTC+3]
4. Целевой адрес: [https://api.example.com/v2/data]
5. Что делал: [отправлял GET-запрос из curl]
6. Ожидал: [код 200 и данные]
7. Получил: [ошибку соединения / медленный ответ / код ошибки]

Результаты проверок:
- Другой сайт через этот прокси: [работает / не работает]
- Прямое соединение без прокси: [работает / не работает]
- Другой прокси к той же цели: [работает / не работает / нет второго прокси]

Окружение:
- ОС: [Windows 11]
- Клиент: [curl 8.6.0]
- Настройка прокси: [флаг -x в curl]
- Корпоративный фильтр: [нет / есть, порты 80 и 443]

Вывод диагностики (логин и пароль скрыты) прилагаю в файле diag_clean.txt.

Краткий вывод: по моим проверкам проблема на границе [клиент-прокси / прокси-сервер], потому что [прямое соединение работает, а через прокси нет].

Как правильно заполнить

1. Скопируйте шаблон в тело письма или тикета.
2. Замените каждое поле в квадратных скобках на свои данные.
3. Приложите очищенный файл diag_clean.txt.
4. Перечитайте письмо целиком: понятно ли оно человеку со стороны.
5. Отправьте.

Совет: строка "Краткий вывод" в конце — самая полезная. В ней вы сами формулируете гипотезу на основе проверок. Даже если гипотеза неточна, она показывает инженеру ход ваших мыслей и экономит время.

✅ Проверка: в письме нет ни одного поля в квадратных скобках — все заполнены. Приложен очищенный файл. Есть краткий вывод с гипотезой. Обращение готово к отправке.

Проверка результата: чек-лист готовности обращения

Перед отправкой пройдите по короткому чек-листу. Он гарантирует, что вы ничего не упустили.

• Указан точный идентификатор прокси, а не описание.
• Есть время события с явным часовым поясом.
• Указан полный целевой адрес.
• Описано, что вы делали, что ожидали и что получили.
• Приложен полный вывод curl в подробном режиме.
• Выполнены и описаны минимум две проверки на исключение.
• Указаны ОС, клиент и его версия.
• Из логов удалены пароль и все токены.
• Файл диагностики приложен и назван понятно.
• Есть краткий вывод с вашей гипотезой.

Если все пункты отмечены, ваше обращение относится к тем, что решаются с первого ответа. Инженеру не нужно ничего уточнять — у него есть полная картина.

✅ Проверка: все десять пунктов чек-листа выполнены. Это и есть показатель успеха: обращение самодостаточно.

Типичные ошибки и их решения

Разберём частые проблемы при сборе диагностики и способы их устранить.

Проблема 1: curl выдаёт ошибку сразу, без подключения к прокси

Причина: неверный формат адреса прокси или опечатка в схеме (http вместо socks5 или наоборот).

Решение: проверьте тип прокси в личном кабинете Proxeon и подставьте правильную схему. Убедитесь, что порт указан верно и отделён двоеточием.

Проблема 2: ошибка авторизации на прокси

Причина: неверный логин или пароль, либо специальные символы в пароле не экранированы.

Решение: перепроверьте учётные данные. Если в пароле есть символы @, :, / — они могут ломать строку. В таком случае передайте авторизацию отдельным флагом

--proxy-user ЛОГИН:ПАРОЛЬ

Проблема 3: скрипт не запускается в Windows

Причина: политика выполнения PowerShell блокирует локальные скрипты.

Решение: запустите PowerShell от имени администратора и разрешите выполнение для текущего сеанса командой установки политики RemoteSigned на уровне процесса. После сбора данных верните исходную политику.

Проблема 4: в выводе нет подробностей, только итоговая строка

Причина: забыт флаг -v, который включает подробный режим.

Решение: добавьте -v сразу после curl. Именно он показывает построчный ход соединения, без которого диагностика бесполезна.

Проблема 5: пароль случайно остался в отправленном файле

Причина: очистка выполнена невнимательно, пароль встретился в строке вывода, а не только в команде.

Решение: немедленно смените пароль прокси в личном кабинете Proxeon. Впредь всегда выполняйте поиск по паролю в очищенном файле перед отправкой.

Проблема 6: проблема не воспроизводится в curl, но есть в браузере

Причина: браузер добавляет заголовки, cookie или использует иной способ настройки прокси.

Решение: в обращении честно укажите, что в curl проблема не повторяется, а в браузере есть. Приложите название и версию браузера и способ настройки прокси в нём. Это само по себе диагностическая информация.

Проблема 7: время в логах не совпадает с вашим

Причина: вы указали местное время без часового пояса, а сервер работает в UTC.

Решение: всегда указывайте пояс явно. Если сомневаетесь, приложите обе метки: своё местное время и его эквивалент в UTC.

Дополнительные возможности: продвинутая диагностика

Если базового набора мало, вот несколько инструментов для более глубокого анализа. Они пригодятся продвинутым пользователям.

Детальные тайминги для проблем со скоростью

Когда прокси работает, но медленно, важно понять, на каком этапе теряется время. Расширенный флаг -w покажет разбивку.

curl -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" -x http://ЛОГИН:ПАРОЛЬ@ХОСТ:ПОРТ https://ЦЕЛЬ

Эти цифры показывают, сколько ушло на разрешение имени, установку соединения, шифрование и получение первого байта. Если велик ttfb, задержка на стороне цели. Если велик connect, проблема в сети до прокси.

Повторяемость проблемы

Если проблема плавающая, соберите серию запросов и покажите, что часть проходит, а часть нет. Простой цикл из нескольких запросов с записью кодов ответа даст статистику. Стабильность или её отсутствие — важный факт для поддержки.

Проверка нескольких целей разом

Составьте список из трёх-четырёх адресов и прогоните их через прокси одной серией. Так вы сразу увидите, специфична проблема для одной цели или общая.

Совет: продвинутые данные прикладывайте только если базовой диагностики не хватило. Избыток информации без структуры так же вреден, как её недостаток. Начинайте с минимума, углубляйтесь по запросу инженера.

FAQ: частые вопросы по сбору диагностики

Обязательно ли использовать именно curl?

Нет, но curl — самый универсальный и понятный инженеру инструмент. Его вывод одинаков на всех системах. Если вы работаете через библиотеку в коде, приложите и её вывод, но curl-проверка всё равно ценна как эталон.

Что делать, если проблема уже прошла и не повторяется?

Зафиксируйте всё, что помните: примерное время, цель, характер ошибки. Приложите логи вашего приложения за тот период. Даже неполные данные с точным временем помогут найти запись на сервере.

Нужно ли прикладывать логи, если ошибка очевидна из описания?

Да. То, что кажется очевидным вам, требует подтверждения фактами. Логи снимают догадки и позволяют дать точный ответ, а не предположение.

Можно ли отправить логин и пароль, чтобы поддержка сама всё проверила?

Нет. Секреты не передаются в переписке. У поддержки Proxeon есть доступ к вашей учётной записи по идентификатору без пароля. Идентификатора достаточно для проверки на стороне сервера.

Как быстро приходит ответ, если всё собрано правильно?

Полное обращение сокращает время до решения в разы, потому что убирает цикл уточнений. Точные сроки зависят от загрузки поддержки, но вы точно избегаете нескольких кругов переписки.

Что если curl показывает успех, а приложение всё равно не работает?

Это ценный факт: проблема не в прокси как таковом, а в том, как приложение его использует. Укажите это в обращении, приложите настройки прокси в приложении и его версию.

Нужно ли указывать целевой адрес, если он публичный?

Да, обязательно. Поведение прокси может зависеть от конкретной цели. Без адреса инженер не сможет воспроизвести именно ваш случай.

Как понять, мой это порт или требуется другой?

Порт указан в карточке прокси в личном кабинете. Разные типы прокси используют разные порты. Сверьтесь с личным кабинетом и не подставляйте порт наугад.