Один SQL-запрос за раз, названия таблиц и столбцов заключить в обратный апостроф `.
И character set сохранять-восстанавливать нет смысла, тем более комментариями, которые в чистом SQL-запросе - ни к селу, ни к городу. Вы же не MYSQL dump восстанавливаете, ну?!
Так вот, в /etc/nginx/sites-available/ создайте ещё один файл site.com.conf, и в него и внесите...
Не забудьте только подправить конфиг, указав "root /var/www/..../" - корневую директорию вашего site.com:1337.
В данном случае var_dump() будет бесполезен, потому что он улетит как ответ на HTTP-запрос с сервера Yandex.
Нужно делать error_log("DEBUG: ".print_r($requestBody, true));, и смотреть в error.log HTTP-сервера, или в debug.log сайта (если сайт перехватывает STDERR).
Ну сделайте var_dump($_FILES);exit();, и смотрите, может вы по массиву неправильно проходите... Но тогда бы были ошибки о использовании неопределённых переменных.
Для проверки, на виртульной машине выполните команду netstat -natp |grep LIST, и смотрите вывод, есть там mysql или нет. Если нет - значит порт и не используется, всё через socket.
Вообще-то да, на конкретном устройстве этот IP прописать можно, но этим вы загрузите свою сеть "по самое небалуйся". Потому-что ЛЮБОЙ пакет данных, посланный на этот IP, будет доставлен/обработан ВСЕМИ устройствами сети. Так что вперед и с песней, поставьте туда какой-нибудь очень высоконагруженный файловый или SQL-сервер, и увольняйтесь побыстре...
И character set сохранять-восстанавливать нет смысла, тем более комментариями, которые в чистом SQL-запросе - ни к селу, ни к городу. Вы же не MYSQL dump восстанавливаете, ну?!