Host-Eiweb

Возможно, что вам мешает это сделать?

Оставайся под виндой, ты там нужнее.

Ну почему вы смотрите только полиси дефолтные как будто других правил там нет
Это как сказать что семена надо навозом посыпать и тогда будет расти, вот сосед в чернозем посадил и навозом поливает и у него растет, а я в глиномес и у меня не растет

Ни VPN, ни прокси не спасет. Сколько уже раз писал - есть технология "отпечатка браузера", которой вообще пофиг прокси, VPN и прочее - она идентифицирует конкретный конечный браузер и ось. Поставьте несколько браузеров - FF, хром, ЯБ, ишака, оперу.
Еще более надежный метод - поставить несколько виртуалок и в каждой разный браузер.

Есть :)
Найти другую работу. Потому что изыскания способов обойти корпоративную защиту могут привести к тому, что окажешься вне этой самой защиты :)

направление, в котором работать

1. Определите, какую нагрузку вы хотели бы выдерживать. Если не статистических данных, сделайте educated guess / ткните пальцем в небо. Без конкретной цифры любая работа теряет вектор и становится неэффективной.
   
2. Определите, какую нагрузку вы выдерживаете сейчас. Это то, что предложил ffosters.
   
3. Если второе число больше первого - вы победили.
   
4. Если реальная пропускная способность меньше желаемой, определите самое узкое место. Что создаёт наибольший процент тормозов? Слабый процессор, малое количество памяти, медленный диск, неоптимальные запросы к БД, запросы на внешние ресурсы, отсутствие кеширования в критичных местах, простые ошибки - всё это ваши вероятные противники.
   
5. Опрелелив узкое место, оптимизируйте его и возвращайтесь к предыдущему пункту. И так до тех пор, пока не станете держать желаемую нагрузку.
   
6. Ну и в качестве вишенки на торте - не стесняйтесь убирать на время ожидаемой нагрузки второстепенный функционал. Хорошо работающий сайт с основными функциями намного полезнее и для вас и для клиентов, чем лежащие свистелки.
   

Если для вас это сложно, а проект действительно важный (так и есть, раз запускается реклама), обратитесь за помощью к профессионалам. По железу мы обращались за консультацией к ребятам во flant.ru. Не всё было гладко, но ощутимую пользу они принесли. По коду они нам не очень помогли, потому что на больших проектах человек со стороны, да ещё и без личного присутсвия рядом с программистами, мало что поймёт.

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

Веста, в варианте Nginx+PHP-FPM, из коробки, фактически не работоспособна, из-за своих кривых и малочисленных шаблонов.

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

Т.е. ваша задача просто не решается без переписывания логики генерации шаблонов пула php-fpm в панельке.

127.0.0.1 может отдать кто угодно, потому что этот адрес никого не обозначает :)

откуда мне начать?

Думаю стоит начать с приглашения специалиста.

Может ли быть проблема в компьютерах из кабинета №2? Возможно ли, что они блокируют доступ к интернету во всей школе?

Нет.

Vesta CP

Не советую это делать.
Лучше оптимизируйте сервер, что бы он не падал.

Highload — это когда традиционных подходов и стандартных решений уже не хватает.

Inxi представляет обширную выводимую информацию в более читаемом виде, чем другие утилиты и имеет множество параметров для её группировки. Пакет оказывает неоценимую помощь при использовании консольного linux-а, в том числе при удалённом подключении через туннель ssh.

sudo yum install epel-release
sudo yum install inxi
Как пользоваться написано тут:
www.binarytides.com/inxi-system-information-linux

Ну надо быть полным идиотом чтобы думать что впс и конфиденциальность совместимы
очевидно что нужен дедик с полным шифрованием диска.

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

1. VPS c 2мя ядрами проца, SSD и минимум 4Гб оперативы (потому что у вас много сайтов и всем нужно раздать места в кеше), у нормального хостера который не оверселлит, по крайней мере явно. Проверенные - Amazon AWS, Digital Ocean. Да, и без swap.
2. FreeBSD
3. Nginx, сертификаты Let's Encrypt, HTTP/2
4. PHP-FPM 7.1
5. MariaDB 10.2
6. Memcached или Redis
7. Адекватные настройки всего этого дела
8. Адекватные плагины кеширования (drop-ins для объектного кеша и для full-page кеширования где оно имеет смысл)
9. Все упомянутые сервисы через сокеты
10. Опционально - Varnish, HAProxy для SSL termination, Nginx fastcgi_cache для кеширования страниц целиком (где в этом есть смысл, вместо плагина на уровне WP)
11. Для управления всем этим не использовать Plesk, Vesta, ISP и прочую ересь. Учитесь делать все руками и самостоятельно.

Вообще, как говорится, дьявол всегда кроется в деталях. Иногда вопрос упирается исключительно в настройки - то fpm pool некорректно настроен, то open table cache в MySQL, то слишком долгий keep alive у Nginx, то упираетесь в лимит открытых файлов, то не кешируется достаточное количество файловых дескрипторов и тд. Корректные настройки всех сервисов под конкретные потребности конкретных сайтов - ключ к успеху.

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

Берёте и сносите к чертям всё это и ставите с нуля.