FiveM sv_filterRequestControl คืออะไร? วิธีตั้งค่า Network Control ให้ปลอดภัยและไม่ทำ Resource พัง

August 11, 2026

FiveM sv_filterRequestControl คือ Server ConVar สำหรับกำหนดนโยบายว่า FXServer จะอนุญาตหรือบล็อก REQUEST_CONTROL_EVENT อย่างไร ซึ่ง Event ประเภทนี้เกี่ยวข้องกับการขอควบคุม Networked Entity ระหว่าง Clients เช่น Vehicle, Ped หรือ Object ภายใต้ระบบ Networking ของ FiveM.

ค่าปัจจุบันรองรับตั้งแต่ -1 ถึง 4 โดยแต่ละ Mode มีระดับการกรองแตกต่างกัน ตั้งแต่ ไม่กรองเลย ไปจนถึง ไม่ Route REQUEST_CONTROL_EVENT เลย นอกจากนี้เมื่อเปิด Mode ที่ไม่ใช่ 0 ยังมีข้อกำหนดเพิ่มเติมเกี่ยวกับ Routing Bucket และ Entity Lockdown อีกด้วย.

สำหรับ Server Owner จุดสำคัญคือ อย่าตั้ง Mode สูงสุดทันทีเพราะคิดว่ายิ่งสูงยิ่งดี เนื่องจาก Resource บางตัวอาจพึ่ง Network Control Request ในการจัดการ Entity การเปลี่ยน Policy โดยไม่ทดสอบจึงอาจทำให้รถ, Ped หรือ Object บางระบบทำงานผิดปกติได้

① sv_filterRequestControl คืออะไร

sv_filterRequestControl เป็น Console Variable ของ FXServer

รูปแบบ:

sv_filterRequestControl [mode]

สามารถกำหนดใน server.cfg เช่น:

set sv_filterRequestControl 2

หรือ:

set sv_filterRequestControl 3

หน้าที่หลักคือกรองการ Route ของ:

REQUEST_CONTROL_EVENT

ตาม Policy ที่กำหนด.

② REQUEST_CONTROL_EVENT คืออะไร

ใน FiveM Networked Entity อาจมี Client หนึ่งเป็น Current Network Owner

หาก Client อื่นต้องการควบคุม Entity ดังกล่าว อาจมีการร้องขอ Network Control ผ่านระบบ Networking

ฝั่ง Client มี Native ที่เกี่ยวข้อง เช่น:

NetworkRequestControlOfEntity(entity)

และ:

NetworkHasControlOfEntity(entity)

สำหรับขอและตรวจ Network Control ของ Entity ตามลำดับ.

แนวคิดคือ:

Client A
เป็น Owner ของ Entity

Client B
ต้องการควบคุม Entity

↓
Request Control
↓
Server Policy ตรวจสอบ
↓
Route หรือ Block

sv_filterRequestControl ทำงานอยู่ในขั้นตอน Policy นี้

③ ทำไม FiveM ต้องมี Request Control Filtering

ใน Server ที่มี Networked Entities จำนวนมาก การอนุญาต Control Request ทุกกรณีอาจไม่เหมาะกับ Architecture ที่ต้องการให้ Server มี Authority มากขึ้น

Cfx.re จึงมี Policy สำหรับบล็อก Control Requests ตาม:

Entity Ownership
Entity อายุเท่าไร
Routing Bucket
Entity Lockdown
Policy Mode ที่ Server เลือก

รายละเอียดเหล่านี้ถูกกำหนดไว้ใน sv_filterRequestControl.

④ sv_filterRequestControl มี Mode อะไรบ้าง

ปัจจุบัน Cfx.re ระบุ:

โดยแต่ละ Mode ไม่ได้หมายถึงระดับความปลอดภัยแบบง่ายๆ ว่าเลขมากกว่าแล้ว “ดีกว่า” เสมอ แต่หมายถึง Policy ที่เข้มขึ้นตามชนิด Entity และการ Route Control Request.

⑤ Mode 0 คืออะไร

sv_filterRequestControl 0

หมายถึง:

Off

และเป็น Default ปัจจุบัน

Cfx.re ระบุว่า Mode 0 ยังปิด Policy ที่อิง Routing Bucket และ Entity Lockdown สำหรับ Request Control Filtering ด้วย.

ตัวอย่าง:

set sv_filterRequestControl 0

เหมาะกับ Server ที่ต้องการ Behavior แบบไม่กรอง REQUEST_CONTROL_EVENT ด้วย ConVar นี้

⑥ Mode 0 เหมาะกับใคร

เหมาะในสถานการณ์ เช่น:

กำลังทดสอบ Resource เก่า
ต้องการ Compatibility สูง
กำลัง Debug ว่าปัญหา Network Control มาจาก Filter หรือไม่
Resource จำนวนมากยังพึ่ง Client Ownership

แต่ไม่ได้หมายความว่า Mode 0 คือค่าที่เหมาะที่สุดสำหรับ Production Server ทุกแห่ง

ควรเลือกจาก Architecture และการทดสอบจริง

⑦ Mode 1 คืออะไร

sv_filterRequestControl 1

Cfx.re ระบุว่า Mode นี้จะ Block Control Request ไปยัง Entity ที่ ถูกควบคุมโดย Player และอยู่มานานกว่า sv_filterRequestControlSettleTimer

ในคำอธิบายปัจจุบัน Entity ประเภทนี้หมายถึง occupied vehicles ในส่วนของ Mode 1.

พูดง่ายๆ:

รถมี Player ควบคุม
+
Entity อยู่มานานเกิน Settle Timer
↓
Control Request ถูก Block

⑧ Settled Entity คืออะไร

เอกสารใช้คำว่า settled สำหรับ Entity ที่มีอายุมากกว่าเวลาที่กำหนดใน:

sv_filterRequestControlSettleTimer

ค่า Default ปัจจุบันคือ:

30000 milliseconds

หรือประมาณ:

30 วินาที

และ Timer นี้มีผลกับ Filter Mode 1 และ 3.

⑨ Mode 1 มีประโยชน์อย่างไร

Mode 1 เป็นแนวทางที่ไม่เข้มเท่า Mode 2–4 เพราะยังไม่ได้ Block ทุก Entity ที่ Player ควบคุมทันที

มันใช้เงื่อนไขเรื่อง Entity ที่ถูกมองว่า Settled เพิ่มเข้ามา

จึงเหมาะกับ Server ที่ต้องการเริ่มเพิ่ม Filtering แต่ยังไม่ต้องการปิด Control Requests กว้างเกินไป

⑩ Mode 2 คืออะไร

sv_filterRequestControl 2

Cfx.re ระบุว่า Mode 2:

Block Control Requests ไปยัง Entity ทั้งหมดที่ Player เป็นผู้ควบคุม.

ไม่ต้องรอ Entity อายุเกิน Settle Timer แบบ Mode 1

จำง่ายๆ:

Entity มี Player ควบคุม
↓
Request Control
↓
Block

⑪ Mode 2 ต่างจาก Mode 1 อย่างไร

Mode 1

Block เฉพาะกลุ่มที่เข้าเงื่อนไข Settled ตาม Policy

Mode 2

Block Entity ที่ Player ควบคุมทั้งหมด

ดังนั้น Mode 2 เข้มกว่า Mode 1 อย่างชัดเจน.

⑫ Mode 3 คืออะไร

sv_filterRequestControl 3

Mode 3 Block:

Entity ทั้งหมดที่ Player ควบคุม
รวมถึง Settled Non-player Entities

ตาม Policy ที่ Cfx.re ระบุ.

จึงกว้างกว่า Mode 2

⑬ Non-player Entity หมายถึงอะไร

ในบริบทของ Policy นี้ หมายถึง Entity ที่ไม่ได้อยู่ในกลุ่ม Player-controlled ตามเงื่อนไขข้างต้น แต่ยังสามารถถูกจัดว่า Settled และถูก Block ใน Mode 3

ดังนั้น Mode 3 สามารถกระทบ Resource ที่พยายาม Request Control ของ Entity Environment หรือ Entity ที่ไม่มี Player ควบคุมด้วย

⑭ Mode 3 ใช้ Settle Timer หรือไม่

ใช้

Cfx.re ระบุว่า:

sv_filterRequestControlSettleTimer

มีผลกับ Mode:

1
3

โดย Default:

30000 ms

⑮ Mode 4 คืออะไร

sv_filterRequestControl 4

เป็น Policy ที่เข้มมาก

Cfx.re ระบุว่า:

ไม่ Route REQUEST_CONTROL_EVENT เลย.

จำง่ายๆ:

Client Request Control
↓
Server
↓
ไม่ Route Event

⑯ Mode 4 หมายความว่า Entity จะไม่มี Owner หรือไม่

ไม่ใช่

Mode 4 ไม่ได้ปิดระบบ Entity Ownership หรือ OneSync

มันกำหนดเพียงว่า:

REQUEST_CONTROL_EVENT

จะไม่ถูก Route ผ่าน Serverตาม Policy นี้.

Entity Ownership, Migration, Scope และ Server-side Entity Synchronization ยังคงเป็นคนละส่วนของ OneSync

⑰ Mode 4 ควรใช้ทันทีหรือไม่

ไม่ควรเปิด Production ทันทีโดยไม่ทดสอบ

Resource เก่าหรือ Resource ที่พึ่ง:

NetworkRequestControlOfEntity(...)

อาจทำงานต่างไปเมื่อ Control Requests ไม่ถูก Route

ควรทดสอบ Resource สำคัญก่อน เช่น:

Garage
Vehicle Management
Entity Cleanup
Persistent Vehicle
NPC/Ped Systems
Object Systems
Instance Resources

⑱ Mode -1 คืออะไร

Cfx.re ระบุว่า:

sv_filterRequestControl -1

ปัจจุบันมี Behavior เทียบเท่า Mode 2 แต่จะมีการ Warning ใน Console เพิ่มด้วย.

ดังนั้นไม่ควรมอง -1 ว่าเป็น Mode ที่เบากว่า 0

⑲ ตาราง sv_filterRequestControl

Mode	Behavior หลัก
`-1`	ปัจจุบันเทียบเท่า 2 และมี Console Warning
`0`	Off / Default
`1`	Block Player-controlled Entity ที่ Settled ตาม Policy
`2`	Block Player-controlled Entities ทั้งหมด
`3`	Mode 2 + Settled Non-player Entities
`4`	ไม่ Route REQUEST_CONTROL_EVENT เลย

ข้อมูลตาม Server Commands Documentation ปัจจุบันของ Cfx.re.

⑳ Routing Bucket เกี่ยวข้องอย่างไร

เมื่อ sv_filterRequestControl ใช้ Mode ที่ ไม่ใช่ Off Cfx.re ระบุว่า:

Control Request Events ไม่สามารถ Route ข้าม Routing Buckets ได้

ตัวอย่าง:

Player
Bucket 10

Vehicle
Bucket 20

↓
Request Control
↓
ไม่ Route ข้าม Bucket

นี่เป็นเหตุผลสำคัญที่ต้องตรวจ Bucket เมื่อ Resource ควบคุม Entity ไม่ได้หลังเข้าสู่ Instance

㉑ ทำไม Player เข้า Instance แล้ว Network Control พัง

สมมติ:

Player = Bucket 100
Vehicle = Bucket 0

Resource พยายาม Request Control Vehicle เดิม

หาก Filtering เปิดอยู่ Request Control ไม่สามารถ Route ข้าม Routing Buckets ตาม Policy ปัจจุบัน.

ดังนั้นต้องแก้ Architecture ให้ Player และ Entity อยู่ Bucket ที่ถูกต้อง ไม่ใช่เพิ่มจำนวนครั้งในการ Request Control

㉒ ตรวจ Player Routing Bucket อย่างไร

ฝั่ง Server สามารถตรวจ:

local bucket =
    GetPlayerRoutingBucket(source)

print(bucket)

Routing Bucket เป็นส่วนหนึ่งของ OneSync และ Player/Entity ที่อยู่คนละ Bucket จะถูกแยก Game State ออกจากกัน.

㉓ ตรวจ Entity Bucket อย่างไร

ใช้:

local bucket =
    GetEntityRoutingBucket(entity)

print(bucket)

ก่อน Debug Control Request ควรเทียบ:

Player Bucket
กับ
Entity Bucket

เสมอ

㉔ strict Entity Lockdown มีผลอย่างไร

เมื่อ Filter Mode ไม่ใช่ 0 Cfx.re ระบุว่า Control Request Event จะถูก Block เสมอ หาก Sender อยู่ใน:

strict entity lockdown

ไม่ว่าจะมาจาก Global Setting หรือ Routing Bucket ของ Player.

นี่เป็นอีกหนึ่งจุดที่สำคัญมาก

㉕ strict + Request Control จะเกิดอะไร

ตัวอย่าง:

Player อยู่ Bucket 100

Bucket 100
Lockdown = strict

sv_filterRequestControl = 2

Player เรียก:

NetworkRequestControlOfEntity(entity)

Control Request สามารถถูก Block ตาม Policy เพราะ Sender อยู่ใน Strict Entity Lockdown.

㉖ ทำไม Request Control 100 ครั้งก็ยังไม่ได้

เพราะปัญหาอาจไม่ใช่เรื่อง “Request ไม่พอ”

แต่เป็น Server Policy:

Routing Bucket
Entity Lockdown
sv_filterRequestControl

กำลัง Block Event อยู่

ดังนั้น Loop:

while not NetworkHasControlOfEntity(entity) do
    NetworkRequestControlOfEntity(entity)
    Wait(0)
end

อาจไม่แก้ต้นเหตุ และยังไม่มี Timeout อีกด้วย

㉗ Request Control ควรมี Timeout

ตัวอย่างที่ปลอดภัยกว่า:

local function requestControl(entity, timeoutMs)
    if not DoesEntityExist(entity) then
        return false
    end

    if NetworkHasControlOfEntity(entity) then
        return true
    end

    local expires =
        GetGameTimer() + timeoutMs

    while GetGameTimer() < expires do
        NetworkRequestControlOfEntity(entity)

        if NetworkHasControlOfEntity(entity) then
            return true
        end

        Wait(50)
    end

    return false
end

แนวคิดสำคัญคือ:

Request
↓
Check
↓
Timeout
↓
Fallback

ไม่ใช่ Loop ไม่สิ้นสุด

㉘ NetworkHasControlOfEntity มีไว้ทำอะไร

ใช้ตรวจว่า Client ปัจจุบันมี Control ของ Entity หรือไม่

if NetworkHasControlOfEntity(entity) then
    -- ทำ Action ที่ต้องใช้ control
end

Native นี้ใช้ตรวจ Network Control ของ Entity โดยตรง.

㉙ NetID กับ Network Control ต่างกันอย่างไร

Network ID บอกว่า:

Entity ตัวไหน

Network Control บอกว่า:

Client นี้ควบคุม Entity ได้หรือไม่

ตัวอย่าง:

NetID = 185

ไม่ได้หมายความว่า Client ที่รู้ NetID 185 จะมี Network Control ของ Entity นั้น

㉚ Entity Owner กับ Control Request ต่างกันอย่างไร

Current Owner คือ Client ที่กำลังเป็น Owner ของ Entity

Server สามารถตรวจ:

local owner =
    NetworkGetEntityOwner(entity)

Cfx.re ระบุว่า Native นี้คืน Owner ID ของ Entity ที่กำหนด.

ส่วน Request Control คือความพยายามจากอีก Context เพื่อขอเปลี่ยน/ได้รับ Control

㉛ Owner สามารถเปลี่ยนได้หรือไม่

ได้

OneSync ใช้ Culling และ Scope และระบุว่าเมื่อ Entity ออกจาก Range ของ Owner เดิม Entity สามารถถูก Culled และ Migrated/Disowned ได้.

ดังนั้น Resource ไม่ควร Cache:

Player A = Owner forever

㉜ Server-created Entity ช่วยอย่างไร

Cfx.re แนะนำ Server-created Entities เป็น Best Practice ของ OneSync และ Server สามารถสร้าง Peds, Vehicles และ Objects ได้เอง.

Architecture:

Client ขอสร้าง Entity
↓
Server Validate
↓
Server Create
↓
Server Set State/Bucket
↓
OneSync Sync

ลดการพึ่ง Client-created Entity และ Control Transfer บางประเภท

㉝ ตัวอย่าง Server-created Vehicle

local vehicle = CreateVehicleServerSetter(
    GetHashKey('blista'),
    'automobile',
    2204.795,
    -887.9213,
    1461.224,
    90.0
)

SetEntityOrphanMode(
    vehicle,
    2
)

Cfx.re ใช้ Structure ลักษณะนี้ใน OneSync Best Practices.

㉞ Entity Orphan Mode คืออะไร

Cfx.re ระบุว่าสามารถใช้:

SetEntityOrphanMode(entity, 2)

พร้อม KeepEntity Flag เพื่อป้องกัน Server ลบ Entity ตาม Lifecycle บางกรณี แม้ Client ยังสามารถร้องขอการลบ Entity ได้.

นี่เป็นคนละระบบกับ sv_filterRequestControl

㉟ RPC Native เกี่ยวข้องอย่างไร

OneSync Documentation ระบุว่า Server Natives บางชนิดเป็น RPC Natives ซึ่งจะถูกเรียกบน Client โดยปกติคือ Client ที่เป็น Owner ของ Entity และการเรียกแบบนี้ ไม่รับประกันว่าจะสำเร็จเสมอ.

ดังนั้น Developer ควรระวัง Architecture ที่พึ่ง:

Entity Owner
+
RPC Native
+
Request Control

มากเกินไป

㊱ State Bags ช่วยลด Request Control ได้ไหม

ในบาง Use Case ได้

หากสิ่งที่ Resource ต้องการคือ Synchronize สถานะ เช่น:

vehicle:locked
vehicle:owner
vehicle:mode

State Bags เหมาะกว่าการพยายาม Request Control เพียงเพื่อส่ง State จาก Client หนึ่งไปอีก Client หนึ่ง

OneSync Documentation แนะนำ State Bags สำหรับ Attribute ของ Entities และยังแนะนำใช้ State Bags แทน Scope Events ในกรณีที่เหมาะสม.

㊲ Event กับ State ต่างกันอย่างไร

จำง่ายๆ:

Network Event
= สิ่งที่เกิดขึ้น

State Bag
= สถานะปัจจุบัน

Network Control
= ใครสามารถควบคุม Entity

สามอย่างนี้ทำงานคนละหน้าที่

อย่าใช้ Control Request แทน State Synchronization หากไม่จำเป็น

㊳ sv_filterRequestControlSettleTimer คืออะไร

เป็น ConVar สำหรับกำหนดว่า Entity ต้องมีอายุเท่าไรจึงถูกนับว่า Settled ใน Policy ที่เกี่ยวข้อง

ค่า Default:

หน่วย:

milliseconds

หรือประมาณ 30 วินาที.

㊴ วิธีตั้ง Settle Timer

ตัวอย่าง:

set sv_filterRequestControlSettleTimer 30000

หรือสมมติต้องการ 20 วินาที:

set sv_filterRequestControlSettleTimer 20000

แต่ Timer นี้มีผลกับ Mode 1 และ 3 เท่านั้นตาม Documentation ปัจจุบัน.

㊵ อย่าลด Settle Timer โดยไม่เข้าใจผล

ถ้าลดจาก:

เป็น:

Entity จะเข้าเงื่อนไข Settled เร็วขึ้นใน Mode ที่ใช้ Timer

จึงอาจทำให้ Resource ที่เคยมีเวลาขอ Control ได้ยาวขึ้นถูก Block เร็วกว่าเดิม

ควรทดสอบก่อนใช้ Production

㊶ ตัวอย่าง server.cfg แบบ Compatibility

set sv_filterRequestControl 0

นี่คือ Off/Default ตาม Documentation ปัจจุบัน.

เหมาะสำหรับ Baseline Test

㊷ ตัวอย่าง server.cfg Mode 1

set sv_filterRequestControl 1
set sv_filterRequestControlSettleTimer 30000

ใช้ Settled Policy ตาม Default Timer

㊸ ตัวอย่าง server.cfg Mode 2

set sv_filterRequestControl 2

Block Requests สำหรับ Player-controlled Entities ตาม Mode 2.

㊹ ตัวอย่าง server.cfg Mode 3

set sv_filterRequestControl 3
set sv_filterRequestControlSettleTimer 30000

Mode นี้ขยายไปถึง Settled Non-player Entities ด้วย.

㊺ ตัวอย่าง server.cfg Mode 4

set sv_filterRequestControl 4

หมายความว่า FXServer จะไม่ Route REQUEST_CONTROL_EVENT ตาม Policy นี้.

ควรใช้หลังทดสอบ Compatibility อย่างละเอียดเท่านั้น

㊻ Server Owner ควรเริ่มจาก Mode ไหน

ถ้า Server เดิมมี Resources จำนวนมากและไม่รู้ว่า Resource ใดพึ่ง Request Control:

อย่าเริ่มจาก 4

แนวทางที่ปลอดภัยกว่าในการ Migration คือ:

Baseline
↓
Mode 0

ทดสอบ Resources
↓
Mode 1 หรือ 2 ตาม Architecture

ตรวจผล
↓
ค่อยพิจารณา Policy ที่เข้มขึ้น

ไม่ควรเปลี่ยน Production จาก 0 → 4 แล้วค่อยตามแก้ Resource ทีหลัง

㊼ Resource ประเภทไหนควรทดสอบก่อน

ให้เน้น Resource ที่จัดการ Networked Entities เช่น:

Vehicle Spawn
Vehicle Persistence
Garage
NPC/Ped
Object/Prop
Entity Cleanup
Routing Bucket
Character Selection
Session/Party
Server-created Entities

เพราะ Resource กลุ่มนี้มีโอกาสเกี่ยวข้องกับ Entity Control มากที่สุด

㊽ NetworkRequestControlOfEntity ไม่ทำงานหลังเปลี่ยน Config

ตรวจ 5 อย่าง:

① sv_filterRequestControl
② Player Routing Bucket
③ Entity Routing Bucket
④ Entity Lockdown
⑤ Current Entity Owner

ก่อนแก้ Code

นี่จะช่วยแยกได้ว่าปัญหาเกิดจาก Resource หรือ Server Policy

㊾ วิธี Debug Current Owner

ฝั่ง Server:

local owner =
    NetworkGetEntityOwner(entity)

print(
    ('Entity %s owner = %s')
    :format(
        entity,
        owner
    )
)

Native นี้ใช้ดู Entity Owner ที่ระบบเห็นอยู่ปัจจุบัน.

㊿ วิธี Debug ฝั่ง Client

local exists =
    DoesEntityExist(entity)

local control =
    NetworkHasControlOfEntity(entity)

print(
    ('exists=%s control=%s')
    :format(
        tostring(exists),
        tostring(control)
    )
)

จากนั้นเทียบกับ:

NetID
Owner
Bucket
Lockdown
Filter Mode

จะได้ภาพครบกว่าเช็คเพียง NetworkHasControlOfEntity

51. Entity อยู่คนละ Bucket แก้อย่างไร

ถ้า Player กับ Entityควรอยู่ Instance เดียวกัน ให้ Server จัด Routing Bucket ให้ตรงกัน

ตัวอย่าง:

local bucket =
    GetPlayerRoutingBucket(source)

SetEntityRoutingBucket(
    entity,
    bucket
)

Routing Buckets แยก Players และ Entities ออกจาก Game State ของ Bucket อื่น.

52. strict Bucket แล้วต้อง Request Control หรือไม่

ถ้า Server Policy ใช้ Filter Mode ที่ไม่ใช่ Off Sender ที่อยู่ Strict Lockdown จะถูก Block Control Request ตาม Documentation.

ดังนั้น Architecture ของ Strict Instance ควรเน้น:

Server-created Entity
Server-side Validation
Server-controlled State

มากกว่าพึ่ง Client Control Requests

53. Entity Lockdown ใช้ทำอะไร

Cfx.re ระบุว่า Entity Lockdown ช่วยให้ Server จำกัด Client Entity Creation และ strict หมายถึง Client ไม่สามารถสร้าง Entities ได้เลยใน Bucket นั้น.

ตัวอย่าง:

SetRoutingBucketEntityLockdownMode(
    100,
    'strict'
)

54. sv_filterRequestControl กับ Entity Lockdown ต่างกันอย่างไร

Entity Lockdown

ควบคุม:

Client สร้าง Entity ได้ไหม

sv_filterRequestControl

ควบคุม:

REQUEST_CONTROL_EVENT ถูก Route หรือ Block

เป็นคนละระบบ แม้มี Policy ที่เชื่อมโยงกันเมื่อ Filter Mode ไม่ใช่ 0

55. sv_filterRequestControl กับ State Bag Strict Mode ต่างกันอย่างไร

ยังเป็นคนละระบบ

`sv_filterRequestControl`

กรอง Request Control Events

`sv_stateBagStrictMode`

ควบคุมว่า Client สามารถแก้ Replicated State Bags ได้หรือไม่

ดังนั้น Server-authoritative Architecture อาจใช้หลาย Policy ร่วมกัน แต่ต้องทดสอบ Compatibility ของ Resources

56. Request Control ไม่ใช่ Permission

การที่ Client Request Control Entity ได้ไม่ได้หมายความว่า Player มี Gameplay Permission

Server Event ที่เกี่ยวข้องยังต้องตรวจ:

Player State
Permission
Session
Position
Inventory
Ownership ในระบบของ Resource

Cfx.re แนะนำให้ข้อมูลสำคัญถูกตรวจด้วย Server-side Methods และไม่เชื่อ Client Input โดยตรง.

57. อย่าเชื่อ NetID จาก Client โดยตรง

ตัวอย่าง Client:

TriggerServerEvent(
    'garage:action',
    netId
)

Server ไม่ควรทำ Action ทันทีเพียงเพราะได้รับ NetID

ควรตรวจ:

NetID มี Entity จริง?
↓
Player มีสิทธิ์?
↓
Entity อยู่ Session เดียวกัน?
↓
Bucket ถูก?
↓
State ถูก?
↓
จึงทำ Action

แนวคิดนี้ตรงกับคำแนะนำของ Cfx.re ที่ให้ Validate Client-triggered Events ฝั่ง Server.

58. AddEventHandler กับ RegisterNetEvent เกี่ยวข้องอย่างไร

Cfx.re แนะนำ:

Event ภายใน Context เดียวกัน

ใช้:

AddEventHandler(...)

Event ที่ต้องข้าม Client/Server

ใช้:

RegisterNetEvent(...)

เพราะการ Register Event เป็น Network Event โดยไม่จำเป็นสามารถเพิ่มพื้นผิวที่ Client เรียกได้.

59. อย่าแก้ Network Control ด้วยการเปิด Event เพิ่ม

ถ้า Resource มีปัญหาจาก Entity Control ไม่ควรแก้ด้วยการเปิด Network Event ที่ให้ Clientส่ง:

delete entity
move entity
change owner

โดยไม่มี Server Validation

ต้องแก้ต้นเหตุที่:

Ownership
Scope
Bucket
Lockdown
Filter Policy

ก่อน

60. Server-created Entity เหมาะกับ Architecture ใหม่

Cfx.re ระบุ Server-created Entities เป็น Best Practice ของ OneSync และ Server สามารถสร้าง Vehicle, Ped และ Object ได้เอง.

สำหรับ Resource ใหม่ จึงควรถามก่อนว่า:

“จำเป็นต้องให้ Client สร้าง Entity นี้หรือไม่?”

ถ้าไม่จำเป็น การให้ Serverสร้างและจัดการ Entity อาจทำให้ Authority ชัดกว่า

61. วิธี Migration Resource เก่า

ใช้ขั้นตอน:

① ตั้ง Filter Mode 0
② ทดสอบ Resource ให้ครบ
③ หา Resource ที่ Request Control
④ แยก Entity สำคัญ
⑤ ย้าย Entity Creation ไป Server เมื่อเหมาะสม
⑥ ใช้ State Bags สำหรับ Runtime State
⑦ ทดสอบ Mode 1/2
⑧ ตรวจ Bucket และ Lockdown
⑨ Load Test
⑩ ค่อยขึ้น Production

ไม่ควรเปลี่ยน Policy หลายตัวพร้อมกัน เพราะจะหาสาเหตุยาก

62. อย่าเปลี่ยน Lockdown และ Filter พร้อมกันครั้งแรก

ตัวอย่าง:

เดิม:
inactive
filter 0

เปลี่ยนพร้อมกัน:
strict
filter 4

แล้ว Resource พัง

จะไม่รู้ว่าปัญหามาจาก:

Client Entity Creation ถูก Block
Request Control ถูก Block
Routing Bucket
Resource Logic

ควรปรับทีละ Policy แล้วทดสอบ

63. Log อะไรตอน Debug

แนะนำให้ Log:

Player Source
Player Bucket
Entity Handle
Entity NetID
Entity Bucket
Entity Owner
Has Control
Filter Mode
Lockdown Mode

ไม่ต้อง Log ทุก Frame

ให้ Log เฉพาะตอน Action Failed จะอ่านง่ายกว่าและลด Console Noise

64. Mode ไหนเหมาะกับ Production Server

ไม่มีค่าเดียวที่เหมาะกับทุก Server

ขึ้นกับว่า Server ใช้:

Client-created Entities มากแค่ไหน
Server-created Entities มากแค่ไหน
Routing Buckets หรือไม่
Strict Lockdown หรือไม่
Resource รุ่นเก่าหรือใหม่
Network Control Request มากแค่ไหน

เป้าหมายคือ ใช้ Policy ที่เข้มเท่าที่ Architecture รองรับโดยไม่ทำ Gameplay พัง

65. Checklist ก่อนเปลี่ยน sv_filterRequestControl

ตรวจให้ครบ:

Backup server.cfg
จดค่าปัจจุบัน
ทดสอบใน Development ก่อน
ตรวจ Vehicle Resources
ตรวจ Ped Resources
ตรวจ Object Resources
ตรวจ Garage
ตรวจ Entity Cleanup
ตรวจ Character Selection
ตรวจ Routing Buckets
ตรวจ Entity Lockdown
ตรวจ sv_filterRequestControlSettleTimer
ตรวจ NetID
ตรวจ Current Owner
ตรวจ Request Control
ทดสอบ Player 2 คนขึ้นไป
ทดสอบ Player เข้า/ออก Scope
ทดสอบคนละ Routing Bucket
ทดสอบ Resource Restart
ทดสอบ Server Restart
ตรวจ Client F8
ตรวจ Server Console
ตรวจ Entity ค้าง
ตรวจ Entity หาย
ตรวจ Player Disconnect

ตารางการเลือก Mode แบบเข้าใจง่าย

สถานการณ์	Mode ที่ควรเริ่มทดสอบ
Resource เก่าจำนวนมาก	`0`
เริ่มเพิ่ม Filtering	`1`
ต้องการ Block Player-controlled Entities	`2`
ต้องการ Policy กว้างขึ้นถึง Settled Non-player Entities	`3`
Architecture ไม่ต้องพึ่ง REQUEST_CONTROL_EVENT	`4` หลังทดสอบเต็มรูปแบบ

ตารางนี้เป็นแนวทางการทดสอบจากพฤติกรรม Mode ที่ Cfx.re ระบุ ไม่ใช่ข้อบังคับว่าทุก Server ต้องใช้ค่าตามนี้.

ตัวอย่าง Configuration สำหรับเริ่มทดสอบ

# Request Control filtering
set sv_filterRequestControl 1

# Default 30 seconds
set sv_filterRequestControlSettleTimer 30000

จากนั้นทดสอบ Resource สำคัญทีละระบบ

ตัวอย่าง Architecture ที่ลดการพึ่ง Request Control

Client
↓
Request Action

Server
↓
Validate Player
↓
Validate Entity
↓
Validate Bucket
↓
Validate State
↓
Server Action / State Update

OneSync
↓
Sync Result

แนวคิดนี้สอดคล้องกับทั้ง OneSync Best Practices และแนวทาง Secure Events ของ Cfx.re.

FiveM NetworkRequestControlOfEntity ไม่ทำงาน แก้อย่างไร

ตรวจตามนี้ก่อน:

DoesEntityExist?
↓
Networked?
↓
NetID ถูก?
↓
อยู่ใน Scope?
↓
Player/Entity Bucket ตรง?
↓
Strict Lockdown?
↓
sv_filterRequestControl Mode?
↓
Current Owner?

หากพบว่า Server Policy ตั้งใจ Block Request อยู่ การเพิ่ม Loop Request Control ไม่ใช่วิธีแก้

FiveM Request Control ไม่ได้เฉพาะใน Routing Bucket

ถ้า Filter Mode ไม่ใช่ 0 Cfx.re ระบุว่า REQUEST_CONTROL_EVENT ไม่สามารถ Route ข้าม Routing Buckets ได้.

ตรวจ:

GetPlayerRoutingBucket(source)
GetEntityRoutingBucket(entity)

ก่อน

FiveM Request Control ไม่ได้เฉพาะ strict Bucket

ตรวจ:

sv_filterRequestControl

ถ้าไม่ใช่ Mode 0 Sender ที่อยู่ Strict Entity Lockdown จะถูก Block Control Request ตาม Policy.

นี่เป็น Behavior ที่ตั้งใจ ไม่ใช่ Bug ของ NetworkRequestControlOfEntity

FiveM Mode 4 ทำ Resource พัง แก้อย่างไร

กลับไปทดสอบ Mode:

เพื่อทำ Baseline ก่อน

ถ้า Resource กลับมาทำงานได้ แสดงว่าต้องตรวจว่า Resource นั้นพึ่ง REQUEST_CONTROL_EVENT ส่วนใด

จากนั้นพิจารณา:

ปรับ Resource
Server-created Entity
State Bags
Server-side Action
หรือเลือก Filter Mode ที่เหมาะกว่า

FiveM Settle Timer ควรเท่าไร

Default ปัจจุบันคือ:

30000 ms

Cfx.re ไม่ได้ระบุว่าทุก Server ควรเปลี่ยนจาก Default ดังนั้นถ้ายังไม่มีเหตุผลและ Benchmark ชัดเจน การเริ่มจาก Default จะ Debug ง่ายกว่า.

FiveM sv_filterRequestControl ช่วยเรื่อง Security ไหม

ช่วยใน Layer ของ Network Control Routing แต่ ไม่ใช่ระบบ Security ทั้งหมดของ Server

ยังต้องมี:

Secure Events
Server-side Validation
ACE Permissions
Entity Lockdown
State Policies
Resource Permissions

ตาม Use Case

Cfx.re แนะนำให้ Server Events ตรวจ Money, State Bags, Inventory, Position, Experience และ Permissions ผ่านข้อมูลฝั่ง Server ไม่เชื่อค่าที่ Client ส่งเข้ามาเอง.

FAQ FiveM sv_filterRequestControl

sv_filterRequestControl คืออะไร

เป็น FXServer ConVar สำหรับกรอง REQUEST_CONTROL_EVENT ตาม Policy ที่กำหนด.

Default ของ sv_filterRequestControl คืออะไร

ปัจจุบัน Default คือ:

หรือ Off.

Mode 1 ทำอะไร

Block Control Requests ไปยัง Player-controlled Entity ตาม Settled Policy โดยใช้ sv_filterRequestControlSettleTimer.

Mode 2 ทำอะไร

Block Requests ไปยัง Entity ทั้งหมดที่ Player เป็นผู้ควบคุม.

Mode 3 ทำอะไร

Block Player-controlled Entities และเพิ่ม Settled Non-player Entities เข้าไปด้วย.

Mode 4 ทำอะไร

ไม่ Route REQUEST_CONTROL_EVENT เลย.

sv_filterRequestControlSettleTimer Default เท่าไร

Default คือ:

30000 milliseconds

และใช้กับ Mode 1 และ 3.

Request Control ข้าม Routing Bucket ได้ไหม

เมื่อ Filter Mode ไม่ใช่ Off Cfx.re ระบุว่า Control Request Events ไม่สามารถ Route ข้าม Routing Buckets.

strict Entity Lockdown มีผลกับ Request Control ไหม

มี เมื่อ Filter Mode ไม่ใช่ Off Control Request จาก Sender ที่อยู่ Strict Entity Lockdown จะถูก Block.

Mode 4 ดีที่สุดหรือไม่

ไม่จำเป็น เพราะ Resource ที่พึ่ง Request Control อาจได้รับผลกระทบ ควรเลือกจาก Server Architecture และทดสอบก่อน Production

NetworkRequestControlOfEntity ต้องใช้ทุกครั้งไหม

ไม่ Resource สมัยใหม่สามารถใช้ Server-created Entities, Server-side Logic และ State Bags ในหลาย Use Cases แทนการพึ่ง Control Transfer ตลอดเวลา.

ประเด็นสำคัญ

FiveM sv_filterRequestControl เป็น Policy สำหรับควบคุมการ Route ของ REQUEST_CONTROL_EVENT โดย Mode ปัจจุบันมี -1, 0, 1, 2, 3 และ 4 ตั้งแต่ Off ไปจนถึงไม่ Route Request Control Event เลย.

จุดที่ Server Owner ต้องจำให้แม่นคือ เมื่อ Filter Mode ไม่ใช่ 0:

Control Request
ข้าม Routing Bucketไม่ได้

และ

Sender ที่อยู่ strict Entity Lockdown
จะถูก Block

ดังนั้นถ้า NetworkRequestControlOfEntity() ไม่ทำงาน อย่าเพิ่ม Loop Request Control ทันที ให้ตรวจ Filter Mode → Player Bucket → Entity Bucket → Lockdown → Current Owner → Scope ก่อน

สำหรับ Resource รุ่นใหม่ Cfx.re แนะนำ Server-created Entities ภายใต้ OneSync และ State Bags สามารถใช้ Sync Runtime State ของ Entity ได้ จึงสามารถลดการพึ่ง Client Ownership และ Control Requests ในหลายระบบ.

ส่วน Network Events ยังคงต้องตรวจข้อมูลฝั่ง Server เสมอ เพราะ Client สามารถเรียก Network Events ได้ และ Cfx.re แนะนำให้ตรวจ Permission, Player State, Position และข้อมูล Gameplay สำคัญด้วย Server-side Methods.

สำหรับผู้อ่าน comsiam ให้จำสูตร “Filter → Bucket → Lockdown → Owner → Control” และ comsiam แนะนำให้เปลี่ยน sv_filterRequestControl ทีละระดับพร้อมทดสอบ Resources จริง ไม่ควรเปิด Mode 4 หรือ Strict Policies หลายตัวพร้อมกันใน Production เพราะเมื่อเกิดปัญหาจะหาต้นเหตุได้ยากมาก