На машине работает, на сервере нет

Классика, но я застрял. Скрипт обхода на ноутбуке отрабатывает весь список из 12 тысяч адресов без единого отказа. Тот же скрипт, тот же файл, тот же интерпретатор по версии, залит на сервер и запущен под systemd: первые сотни три проходят, дальше сплошные 403.

Из консоли на сервере, руками, тот же скрипт работает нормально. Ломается он только когда его запускает служба. Файл один, машина одна, поведение разное.

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

Гадать тут нечего, эту задачу закрывают сравнением. Ловушка в том, что сравнивать надо всё подряд, включая скучное. Виновата обычно самая незаметная строчка, на которую взгляд не задерживается.

Три уровня сравнения, по возрастанию мороки.

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

# в скрипт временно, самой первой строкой
env | sort > /tmp/env-$(id -un)-$$.txt

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

Третий, самый честный: снимите сырой запрос с обоих запусков и сравните побайтно. Всё, что скрипт реально отправил, видно только там. Заголовки, их порядок, кодировки, имя клиента.

Начните с первого, в девяти случаях из десяти он и закрывает вопрос.

Снял. Разница в двенадцать строк, из них половина про пути. И ещё вот это:

< HTTP_PROXY=http://10.0.0.9:3128
< HTTPS_PROXY=http://10.0.0.9:3128
< NO_PROXY=localhost,127.0.0.1

Треугольные скобки означают, что в окружении службы их нет вовсе.

то есть из-под службы он ходил напрямую? а сайт это заметил?

Именно так и заметил. Триста обращений подряд с одного адреса за пару минут любая площадка видит без труда, дальше 403 до конца прогона.

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

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

Костя, лечится в два касания.

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

[Service]
EnvironmentFile=/etc/progon/okruzhenie
ExecStart=/opt/progon/venv/bin/python /opt/progon/obhod.py

В /etc/progon/okruzhenie кладёте те самые три строки. Права на файл поставьте 600, там пары входа.

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

Вот этот пункт стоит выписать на бумажку и повесить над столом. Он же ловит людей на cron, там ровно та же беда с урезанным окружением.

Отчитываюсь, всё сошлось.

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

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

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