Перейти до контенту
Захист DDoS · Peeryx · 15 Tbps+
Усі посібники

Захист FiveM: HTTP, UDP і origin мають працювати разом

Підключення та гра у FiveM використовують кілька мережевих етапів. Reverse proxy може захищати конкретні HTTP-запити, але не автоматично весь ігровий трафік. Рішення має узгодити оголошені адреси, файли, UDP та обмеження origin так, щоб справжні клієнти могли далі грати.

← Усі посібникиCubixServ

Перед початком

Збережіть призначений ігровий порт, артефакт, публічну адресу й шлях файлів. Опишіть керування та наявний проксі. Залиште конфігурацію, погодьте правила доступу й безпечний адміністративний шлях до переміщення трафіку.

Поділіть з’єднання на етапи

Визначте, як клієнт отримує інформацію сервера, оголошені точки підключення та файли ресурсів і як заходить у гру. Етапи можуть мати різні помилки й потреби захисту. Відповідь однієї сторінки не підтверджує решту. Тестуйте справжнім клієнтом FiveM і порівнюйте F8 із журналом того самого підключення до зміни архітектури.

Також перевірте доменні адреси, старі загальнодоступні адреси та кінцеві точки, рекламовані FXServer. Додаткова служба може розкрити джерело, навіть якщо основне посилання використовує проксі. Використовуйте цей перелік, щоб визначити сферу дії з постачальником.

Налаштуйте HTTP-проксі точно

Користуйтеся документацією Cfx.re для поточного артефакту. Публічний URL, сертифікат і пересилання мають узгоджуватися. Обмеження файлового доступу через проксі повинно підтримуватися версією та відповідати рішенню. Назвати весь інтернет довіреним проксі означає скасувати обмеження; підтвердьте конкретні мережі джерела, а не відкривайте origin для приховування помилки конфігурації.

Якщо ви використовуєте кеш файлів, перевірте призначення та умови доступу. Параметри проксі та файлів залежать від версії FXServer. Налаштування в новішій документації може бути відсутнім у старішому артефакті: перевірте наявність перед зміною конфігурації.

Перевірте UDP окремо

Звичайний HTTP-проксі не є універсальним UDP-посередником. Окремо підтвердьте ігрову адресу, UDP, можливий голос і шлях відповідей. Стара Linux-інструкція Legacy не доводить сумісності Enhanced. Тестуйте конкретний клієнт і артефакт перед заявою про готовність: спільна назва продукту не означає однакової мережевої архітектури чи ідентичних вимог до протоколів.

Зберігайте точні, задокументовані списки надійних джерел. Глобальна надбавка або неправильна адреса проксі-сервера можуть підірвати захист; неправильно розміщений блок може зупинити приєднання гравців. Обертання IP або порту не замінює захист джерела, і його не слід описувати як автоматичне без доставленого механізму.

Закрийте обхідні шляхи без втрати керування

Інші прямі IP або порти можуть обходити проксі. Перевірте DNS, раніше оприлюднені адреси й інші служби origin. Обмежуйте доступ за погодженою архітектурою, але зберігайте окреме адміністрування та повернення. Змінюйте одне правило, тестуйте дозволені з’єднання й перевіряйте, що випадкові входи справді закриті, а не просто приховані від користувача.

Не показуйте базу даних або інструмент адміністрування публічно без визначеної потреби та належного контролю. Панель хостингу та txAdmin є окремими середовищами; захист одного не гарантує безпеки іншого. Підтримувати програмне забезпечення та переглядати доступ після зміни команди.

Не обіцяйте автоматичну ротацію IP

Зміна IP чи порту потребує оновлення маршруту, оголошених адрес і клієнтського шляху. Вона не вирішує всі атаки. Називайте процес автоматичним лише з перевіреною інтеграцією й процедурою. Плануйте DNS, активні з’єднання та відновлення; інакше сама зміна може спричинити нове переривання або недоступність завантаження файлів.

Відстежуйте повторювані помилки та операції, які стають дорогими під навантаженням. Тестуйте зміни на копії, зберігайте попередні версії та керуйте залежностями. Рамки та ресурси потребують обслуговування; додавання захисту не робить сценарії автоматично безпечними.

Підтвердьте малим тестом

Перевірте підключення, файли й гру з незалежних мереж із малим дозволеним навантаженням. Стежте за ресурсами, тайм-аутами та журналами до і після. Відокремте мережеву проблему від помилки ресурсу або незавершеного запуску. Передавайте оператору лише потрібні для розслідування журнали без ключів і токенів, щоб перевірка не створювала нового ризику доступу.

Під час інциденту збережіть час, уражені мережі, повідомлення та доступні події пом’якшення. Розрізняйте насичення, помилкові спрацьовування, збої ресурсів і помилки адміністрування. Координуйте активні тести з постачальником, а не надсилайте імпровізований завантажувальний трафік у виробництво.

Що робити у вашій ситуації?

СитуаціяНаступний крок
Зупиняється HTTP-етапДослідіть проксі, сертифікат і публічну адресу файлів.
Файли працюють, гра ніОкремо тестуйте UDP, ігрову адресу й зворотний шлях.
Потрібна нова публічна адресаПогодьте перенесення та план повернення з оператором.

Офіційні джерела

Джерела описують протоколи й налаштування. Перевірте документацію саме вашої версії.

  1. Cfx.re/docs/server-manual/proxy-setup/
  2. Cfx.re/docs/server-manual/server-commands/
  3. Cfx.re/docs/developers/server-security/
  4. RFC Editor / IETF/rfc/rfc4732