Tối ưu và cấu hình Proxy Velocity

Sau khi đã chọn Velocity làm proxy cho network, nhiều người dừng lại ở bước "cài xong, chạy được". Velocity chạy tốt ngay khi mới cài, nhưng "chạy được" và "được cấu hình đúng cho tải thật" là hai việc khác nhau. Một proxy cấu hình sai vẫn có thể hoạt động bình thường ở vài chục người chơi, rồi mới lộ vấn đề khi network đông lên: timeout khi chuyển server, CPU proxy tăng bất thường, hoặc tệ hơn là backend bị lộ ra ngoài vì thiếu một bước bảo mật.

Bài viết này đi sâu vào cách tối ưu và cấu hình Velocity: phân bổ tài nguyên, các mục quan trọng trong velocity.toml, JVM flags được khuyến nghị, forwarding, bảo mật backend và cách theo dõi proxy khi network đã lên tải thật. Nếu bạn chưa quyết định có nên dùng Velocity hay không, bài so sánh Velocity, Waterfall và BungeeCord sẽ phù hợp hơn để đọc trước.

Lưu ý phiên bản: Bài được Research và Update ngày 14/09/2026. Theo Getting Started hiện hành, Velocity yêu cầu tối thiểu Java 25. Cấu hình chính nằm trong velocity.toml; tên setting có thể khác giữa các nhánh cũ và mới, vì vậy hãy đối chiếu đúng bản bạn đang chạy tại trang tải Velocity trước khi copy nguyên khối cấu hình từ bài viết cũ.

Tóm tắt nhanh: thứ tự nên làm khi tối ưu Velocity

1. Xác định quy mô mục tiêu (số người chơi đồng thời, số cụm backend) trước khi chọn CPU/RAM cho proxy.

2. Cấp heap theo khuyến nghị chính thức, không cấp toàn bộ RAM máy cho JVM.

3. Thêm JVM flags tối ưu GC theo đúng khuyến nghị của Velocity, không tự chế thêm flag lạ.

4. Khóa một chế độ forwarding (modern/legacy/bungeeguard) và đồng bộ với từng backend.

5. Dựng firewall + bind backend về localhost hoặc tunnel riêng, không chỉ dựa vào forwarding.

6. Xem lại các setting trong mục [advanced] của velocity.toml: rate limit, timeout, compression.

7. Đo bằng tải thật, theo dõi CPU/heap/kết nối, rồi mới chỉnh tiếp thay vì đổi hàng loạt setting cùng lúc.

Velocity tối ưu khác Paper tối ưu ở điểm nào?

Đây là điểm dễ nhầm nhất với người đã quen tối ưu Paper. Với backend Paper, luồng tick chính là nút thắt (bottleneck), nên một CPU đơn nhân mạnh thường quan trọng hơn nhiều lõi. Velocity có mô hình tải khác: nó có thể tận dụng nhiều lõi khi số kết nối đồng thời tăng, nhưng một network nhỏ thường dùng rất ít CPU proxy so với backend gameplay.

Theo tài liệu Tuning của Velocity, Velocity có thể tận dụng nhiều lõi CPU và hiệu năng đơn luồng không quan trọng bằng số lượng core khi cần phục vụ nhiều kết nối đồng thời. Nói cách khác:

Nếu proxy và backend chạy chung máy, hãy chừa đủ CPU cho cả hai nhưng đo trước khi tách tài nguyên. Ở network nhỏ, backend thường là phần nặng hơn; khi lượng kết nối, Geyser hoặc plugin proxy tăng, Velocity mới có thể trở thành nút thắt riêng.

Phân bổ tài nguyên cho Velocity

CPU và mạng

Tài liệu Tuning không đưa ra một cấu hình phần cứng chung cho mọi trường hợp, nhưng nêu rõ nguyên tắc: ưu tiên nhiều lõi hơn là xung nhịp cao, vì Velocity hưởng lợi thật sự từ số core khi xử lý nhiều kết nối cùng lúc. Băng thông mạng cũng cần được tính theo số người chơi đồng thời, không chỉ theo cấu hình CPU.

Tài liệu cũng lưu ý một điểm ít người để ý: các lỗ hổng bảo mật liên quan đến speculative execution (Spectre, Meltdown) có bản vá làm giảm hiệu năng, và Velocity nhạy cảm với việc này hơn bình thường vì bản chất là một ứng dụng mạng. CPU đời 2019 trở về sau thường đã có cơ chế giảm thiểu tốt hơn cho hai lỗ hổng này.

Heap - đừng cấp theo cảm tính

Velocity đưa ra công thức cụ thể thay vì một con số chung:

• Heap cho proxy độc lập (không chạy trong container): khoảng 512 MB cho mỗi 500 người chơi, cộng thêm khoảng 1 GB dự phòng. Ví dụ, muốn phục vụ 1.000 người chơi, nên cấp khoảng 2 GB heap.

• RAM vật lý cho máy chạy proxy: gấp đôi heap rồi cộng thêm 2 GB. Với heap 2 GB, nên có tối thiểu khoảng 6 GB RAM khả dụng cho hệ điều hành và JVM overhead.

• Nếu chạy trong container (Docker, Pterodactyl, Kubernetes): tài liệu cảnh báo không nên cấp toàn bộ RAM container cho heap, vì dễ bị kernel OOM-killer tắt tiến trình đúng lúc đông người nhất. Mức an toàn (dù hơi dè dặt) là cấp khoảng một nửa RAM container cho heap; ví dụ container 4 GB thì để heap khoảng 2 GB.

# Ví dụ ước lượng cho proxy phục vụ khoảng 500 người chơi đồng thời
Heap đề xuất:      ~1.5 GB (512MB mỗi 500 người + ~1GB dự phòng)
RAM máy tối thiểu: ~5 GB (gấp đôi heap + 2GB)

Đây là công thức khởi điểm để tính toán, không phải cam kết cho mọi network. Số plugin proxy, Geyser, anti-bot và log cũng ảnh hưởng tới mức RAM thực tế cần dùng.

JVM Flags cho Velocity

Đây là phần khác biệt rõ nhất so với backend Paper/Purpur, vốn thường dùng bộ Aikar flags. Velocity có khuyến nghị JVM flags riêng, được tối ưu cho khối lượng công việc của một proxy mạng, không phải một game server tick world.

Theo tài liệu Tuning, flags hiện được khuyến nghị là:

-XX:+UseG1GC -XX:G1HeapRegionSize=4M -XX:+UnlockExperimentalVMOptions -XX:+ParallelRefProcEnabled -XX:+AlwaysPreTouch -XX:MaxInlineLevel=15

Các flags này được thêm sau lệnh java nhưng trước tham số -jar, ví dụ:

java -Xms2G -Xmx2G -XX:+UseG1GC -XX:G1HeapRegionSize=4M -XX:+UnlockExperimentalVMOptions -XX:+ParallelRefProcEnabled -XX:+AlwaysPreTouch -XX:MaxInlineLevel=15 -jar velocity.jar

Vì sao chọn G1GC?

Phần lớn các flags trên nhắm vào việc điều chỉnh garbage collector G1 cho phù hợp với Velocity; riêng -XX:MaxInlineLevel=15 có xu hướng cải thiện hiệu năng chung. Trước Java 9, GC mặc định là Parallel GC — một collector dừng toàn bộ ứng dụng (stop-the-world) trong lúc dọn rác, thời gian dừng có thể dài và gây ra các đợt giật khó giải thích. G1 cân bằng tốt hơn giữa throughput và thời gian dừng, đồng thời tương thích từ Java 8 trở lên. Với bộ flags trên, các lần GC pause của Velocity thường dưới 10 mili-giây, lặp lại sau vài phút — mức chấp nhận được cho một proxy Minecraft.

ZGC và Shenandoah: cân nhắc kỹ trước khi đổi

Tài liệu cũng đề cập tới hai lựa chọn khác, nhưng với mức độ khuyến nghị thấp hơn G1:

• ZGC (ổn định từ Java 15): là GC gần như không dừng (concurrent), ưu tiên độ trễ thấp hơn throughput. Velocity ghi nhận một triển khai quy mô lớn dùng ZGC thành công, nhưng khuyến cáo dùng thận trọng vì bản chất proxy cần cả throughput lẫn latency. Nếu chọn ZGC, tham số quan trọng nhất là kích thước heap: nếu ZGC không dọn rác kịp tốc độ proxy tạo ra, các luồng sẽ bị tạm dừng và proxy có cảm giác giật.

• Shenandoah: cũng là GC concurrent, thế hệ, làm nhiều việc song song hơn G1. Tài liệu Velocity cho biết đội phát triển chưa ghi nhận triển khai thành công nào với Shenandoah trong thực tế.

• OpenJ9: JVM thay thế HotSpot, dùng GC gencon mặc định và hoạt động tốt với Velocity, nhưng hành vi runtime khác biệt đáng kể so với HotSpot.

Nói ngắn gọn: G1 với bộ flags khuyến nghị là lựa chọn an toàn cho phần lớn network. Chỉ đổi sang ZGC khi bạn đã đo GC pause bằng công cụ thật (ví dụ Spark hoặc GC log) và xác nhận G1 đang là nút thắt, không phải vì thấy tên "Z Garbage Collector" nghe hiện đại hơn.

Host Velocity ở đâu - hệ điều hành có quan trọng không?

Có! Tài liệu Tuning nêu rõ Velocity đi kèm thư viện native được tối ưu riêng cho nén (libdeflate) và mã hóa, cùng native transport của Netty (epoll trên Linux, kqueue trên macOS). Các bản native này chỉ được xác nhận hoạt động trên Linux x86_64 và aarch64. Velocity vẫn chạy được khi thiếu native, nhưng hiệu năng sẽ giảm. Vì vậy, khuyến nghị chính thức là triển khai production trên Linux x86_64.

Khi Velocity khởi động đúng cách trên Linux, log sẽ thể hiện điều này, ví dụ dòng thông báo dùng kênh epoll, nén bằng libdeflate và mã hóa OpenSSL thay vì phương án Java thuần. Nếu log của bạn không xuất hiện các dòng tương tự, hãy kiểm tra lại hệ điều hành, kiến trúc CPU và phiên bản thư viện hệ thống trước khi kết luận Velocity "chậm hơn quảng cáo".

Các mục cấu hình quan trọng trong velocity.toml

Velocity dùng định dạng TOML, dễ đọc và dễ quản lý bằng Git hơn YAML. File nằm ngay tại thư mục chạy proxy. Bản cấu hình mặc định luôn cập nhật trên GitHub của Velocity — nên đối chiếu trực tiếp thay vì chép lại từ một bài blog cũ.

Root section - những setting nền tảng

Advanced section - nơi thật sự ảnh hưởng hiệu năng và chống spam

Không nên tăng đồng loạt các giá trị "rate limit" và "timeout" chỉ vì muốn "cho chắc". Rate limit thấp là hàng rào chống bot; nới lỏng toàn bộ trong khi chưa gặp vấn đề thật sẽ làm proxy dễ bị tấn công đăng nhập ồ ạt hơn.

Forwarding - chọn đúng một mod

Theo tài liệu Configuring player information forwarding, Velocity hỗ trợ ba chế độ và chỉ được dùng một chế độ tại một thời điểm cho một backend — không thể "trộn" các kiểu forwarding với nhau:

• modern: định dạng riêng của Velocity, forward thông tin người chơi ở dạng nhị phân kèm mã MAC để backend khó bị giả mạo là đến từ đúng proxy. Đây là lựa chọn nên dùng nếu chỉ hỗ trợ Minecraft 1.13 trở lên.

• legacy: tương thích kiểu BungeeCord, hoạt động được với các phiên bản cũ hơn nhưng kém an toàn hơn nếu dùng riêng lẻ.

• bungeeguard: giống legacy nhưng cộng thêm secret key, dùng khi bắt buộc hỗ trợ Minecraft 1.12 trở xuống và không thể tự dựng firewall giữa các tầng (ví dụ trên shared hosting).

Quy tắc chọn đơn giản: hỗ trợ 1.13+ thì ưu tiên modern; nếu bắt buộc hỗ trợ bản cũ hơn mới cân nhắc legacy hoặc bungeeguard. Với Paper dùng modern forwarding, cấu hình proxies.velocity.enabled: true và secret tương ứng trong config/paper-global.yml; backend vẫn phải được khóa mạng đúng cách. Mục settings.bungeecord: true trong spigot.yml dành cho legacy/Bungee-compatible forwarding, không phải bước chung cho modern forwarding.

Bảo mật backend - forwarding không thay thế firewall

Đây là phần dễ bị bỏ sót nhất khi mọi người tập trung vào "tối ưu hiệu năng". Khi dùng proxy, backend thường chạy online-mode=false, nghĩa là về mặt kỹ thuật, bất kỳ ai kết nối trực tiếp vào cổng backend đều có thể giả làm người chơi bất kỳ nếu không có lớp bảo vệ khác. Tài liệu Securing your servers liệt kê rõ, và đặc biệt nhấn mạnh modern forwarding không thay thế firewall.

Các lớp bảo vệ nên kết hợp:

1. Firewall hệ điều hành (iptables/nftables trên Linux, Windows Firewall trên Windows): hiệu quả nhất, không cần cấu hình thêm ở tầng Minecraft, nhưng cần đồng bộ rule mỗi khi thêm proxy hoặc backend mới, và khó dùng trên shared hosting.

2. Velocity modern forwarding: có sẵn miễn phí khi đã bật, hoạt động tốt trên shared hosting nếu nhà cung cấp đã cấu hình đúng, nhưng chỉ áp dụng cho Minecraft 1.13+ và yêu cầu Paper 1.13+ (hoặc FabricProxy-Lite cho Fabric).

3. Bind backend vào 127.0.0.1: đơn giản nếu proxy và backend chạy cùng một máy vật lý và không ai khác có quyền truy cập máy đó; phải đổi phương án nếu sau này tách backend sang máy khác.

4. Tunnel mã hóa (WireGuard, OpenVPN, tinc, spiped...): phù hợp khi proxy và backend nằm trên các máy vật lý khác nhau, mã hóa được cả đường truyền, nhưng cấu hình phức tạp hơn và không khả thi trên shared hosting.

5. Plugin whitelist theo IP: chỉ nên là lớp phòng thủ cuối cùng, vì vẫn có thể bị vượt qua nếu kẻ tấn công có server trên cùng node vật lý với proxy.

Phần lớn các phương án này có thể kết hợp với nhau, và trong hầu hết trường hợp, firewall + modern forwarding là tổ hợp hợp lý cho một network vừa và nhỏ. Ngoài ra, tài liệu bảo mật còn nhắc các nguyên tắc cơ bản mà nhiều người bỏ qua: sao lưu thường xuyên, không chạy proxy/backend bằng tài khoản root hoặc có quyền sudo, cập nhật Velocity/plugin/hệ điều hành đều đặn và dùng mật khẩu đủ mạnh cho mọi dịch vụ liên quan.

Chống bot và spam kết nối

Velocity không có module anti-bot tích hợp sẵn ở tầng sâu như một số proxy chuyên dụng, nhưng có đủ công cụ cấu hình để giảm tải khi bị quét cổng hoặc spam kết nối:

• Dùng login-ratelimit để giới hạn tần suất kết nối từ cùng một IP.

• Dùng command-rate-limit và tab-complete-rate-limit để chặn spam lệnh/tab-complete từ client giả.

• Kết hợp kick-after-rate-limited-commands để tự động đá kết nối cố tình vượt rate limit nhiều lần thay vì chỉ chặn từng gói.

• Với network hay bị bot tấn công diện rộng, cân nhắc thêm plugin anti-bot chuyên dụng ở tầng proxy, nhưng vẫn nên xem log Velocity trước để hiểu rõ dạng tấn công (spam handshake, spam login hay spam packet) trước khi chọn plugin phù hợp.

Đừng đặt các giá trị rate limit về mức cực đoan như một phản xạ. Rate limit quá chặt có thể khiến người chơi dùng mạng chia sẻ IP (ký túc xá, mạng công ty, NAT của nhà mạng di động) bị chặn oan.

Theo dõi Velocity khi network đã có tải thật

Không có Spark tích hợp mặc định như Paper, nhưng Velocity vẫn cung cấp đủ thông tin để theo dõi:

• /velocity dump: xuất thông tin cấu hình và trạng thái proxy, hữu ích khi cần báo lỗi hoặc so sánh cấu hình giữa các lần thay đổi.

• /glist: xem nhanh số người chơi đang online trên từng backend.

• Log khởi động: xác nhận proxy có dùng đúng native transport, libdeflate và cipher tối ưu hay không — đây là dấu hiệu sớm cho biết proxy có đang chạy đúng môi trường khuyến nghị.

• Giám sát hệ thống: theo dõi CPU tổng, heap JVM, số kết nối đang mở (file descriptor) và độ trễ tới từng backend. Nếu bảng điều khiển hosting hỗ trợ xem CPU/RAM proxy theo thời gian thực, hãy dùng nó song song với log thay vì đoán qua cảm giác "server có vẻ giật".

Nếu CPU hoặc heap của proxy tăng bất thường trong khi số người chơi không đổi, hãy nghi ngờ trước tiên: plugin proxy mới cài, thay đổi forwarding chưa test kỹ, hoặc một dạng spam kết nối đang diễn ra — trước khi vội tăng thêm tài nguyên phần cứng.

Quy trình tối ưu Velocity theo từng bước

Bước 1: xác định quy mô mục tiêu

Ghi lại số người chơi đồng thời dự kiến, số backend, có dùng Geyser/Bedrock hay không, và server có chạy trong container hay không. Đây là cơ sở để tính heap và RAM theo công thức ở phần trên.

Bước 2: cấu hình nền tảng trước khi tối ưu sâu

Cài Velocity đúng bản, dùng Java đáp ứng yêu cầu tối thiểu, đặt JVM flags khuyến nghị và cấp heap theo công thức. Chưa vội chỉnh các setting nâng cao trong [advanced].

Bước 3: khóa forwarding và bảo mật backend

Chọn một chế độ forwarding phù hợp với dải phiên bản bạn hỗ trợ, đồng bộ cấu hình ở cả proxy lẫn backend, sau đó dựng firewall và/hoặc bind localhost. Kiểm tra bằng cách thử kết nối trực tiếp vào cổng backend từ một máy bên ngoài — kết nối phải bị từ chối.

Bước 4: tạo tải thử và quan sát

Cho một nhóm người chơi thật (hoặc công cụ giả lập kết nối) vào network, theo dõi CPU, heap, độ trễ và log. Ghi lại số liệu này làm mốc trước khi chỉnh tiếp.

Bước 5: chỉnh từng nhóm setting, đo lại

Chỉ đổi một nhóm setting mỗi lần (ví dụ chỉ đổi compression, hoặc chỉ đổi rate limit), giữ nguyên các phần còn lại, rồi lặp lại kịch bản tải để so sánh trước/sau.

Bước 6: ghi log thay đổi và chuẩn bị rollback

Sao lưu velocity.toml, forwarding secret và danh sách plugin trước mỗi lần thay đổi lớn. Nếu một thay đổi làm gameplay tệ đi (ví dụ người chơi hay bị đá khi chuyển server), quay lại cấu hình cũ ngay thay vì cố "chỉnh thêm cho ổn".

Checklist tối ưu và bảo mật Velocity

Trước khi mở proxy cho người chơi thật

1. Dùng Java đáp ứng yêu cầu tối thiểu của bản Velocity đang chạy.

2. Cấp heap theo công thức 512 MB/500 người chơi + dự phòng; không cấp toàn bộ RAM container cho heap.

3. Thêm JVM flags khuyến nghị (G1GC + các flags đi kèm) vào start script.

4. Chạy proxy trên Linux x86_64 nếu có thể, để tận dụng native library cho nén và mã hóa.

5. Chọn đúng một chế độ forwarding, đồng bộ với cấu hình spigot.yml/loader ở từng backend.

6. Dựng firewall chỉ cho phép IP proxy kết nối tới cổng backend.

7. Bind backend vào 127.0.0.1 nếu chạy chung máy với proxy, hoặc dùng tunnel nếu khác máy.

8. Giữ forwarding secret ngoài Git public.

9. Test kết nối trực tiếp vào backend từ máy ngoài để xác nhận đã bị chặn.

Sau khi network đã hoạt động

1. Theo dõi CPU, heap và số kết nối của proxy trong giờ cao điểm.

2. Theo dõi log khởi động để xác nhận proxy vẫn dùng đúng native transport.

3. Rà soát login-ratelimit, command-rate-limit nếu phát hiện spam kết nối hoặc spam lệnh.

4. Cập nhật Velocity, plugin proxy và Java theo lịch, đọc changelog trước khi nâng cấp.

5. Ghi số liệu trước/sau mỗi lần đổi cấu hình và giữ bản sao lưu để rollback.

6. Nếu MSPT backend cao trong khi proxy vẫn ổn, quay lại xử lý ở tầng Paper thay vì tiếp tục chỉnh proxy.

Khi proxy đã tối ưu nhưng network vẫn chậm

Nếu đã làm đúng các bước trên mà người chơi vẫn phàn nàn về độ trễ hoặc giật, hãy tách rõ nguyên nhân đang nằm ở đâu. Proxy chỉ định tuyến kết nối; nó không tick world, không xử lý entity hay redstone. Nếu độ trễ chỉ xuất hiện trên một backend cụ thể trong khi kết nối vào proxy vẫn nhanh, nhiều khả năng vấn đề nằm ở Paper, không phải Velocity. Bài tối ưu Paper cho server SMP hướng dẫn cách dùng Spark để tìm đúng nguyên nhân ở tầng backend.

Ngược lại, nếu chính việc kết nối vào proxy đã chậm, hoặc CPU/heap của proxy luôn ở mức cao dù số người chơi không tăng, giới hạn có thể nằm ở phần cứng đang thuê cho proxy, hoặc ở đường mạng giữa proxy và backend. Đây là lúc nên xem lại số vCore, RAM và băng thông của gói hosting đang dùng cho lớp proxy, tách riêng khỏi tài nguyên dành cho backend Paper.

Nếu bạn đang cần một nơi chạy cả proxy Velocity lẫn backend Paper với cấu hình mạng ổn định tại Việt Nam, có thể tham khảo Minecraft Hosting của LumineCloud. Dịch vụ hỗ trợ chạy Velocity cùng nhiều backend, có bảng điều khiển xem CPU/RAM theo thời gian thực, chống DDoS và hỗ trợ kỹ thuật tiếng Việt 24/7 — phù hợp để tách proxy và backend ra các gói tài nguyên riêng khi network đã đủ đông để cần mô hình đó.

Câu hỏi thường gặp

Velocity cần bao nhiêu RAM?

Không có một con số cố định cho mọi network. Công thức khởi điểm theo tài liệu chính thức là khoảng 512 MB heap cho mỗi 500 người chơi cộng thêm khoảng 1 GB dự phòng, và RAM máy vật lý nên gấp đôi heap cộng thêm 2 GB. Nếu chạy trong container, không nên cấp toàn bộ RAM container cho heap.

Velocity cần CPU đơn nhân mạnh hay nhiều lõi?

Velocity có thể tận dụng nhiều lõi tốt hơn backend Paper khi tải kết nối lớn, nhưng network nhỏ thường cần rất ít CPU proxy. Hãy chọn theo số kết nối đồng thời, plugin/Geyser, CPU thực đo và băng thông; không áp dụng máy móc nguyên tắc của Paper hoặc mua nhiều core khi chưa có số liệu.

Có cần dùng đúng JVM flags khuyến nghị không?

Nên dùng, đặc biệt là bộ flags G1GC được Velocity khuyến nghị chính thức. Đây là bộ flags được tinh chỉnh riêng cho khối lượng công việc của proxy, khác với bộ flags tối ưu cho backend game server.

Modern forwarding có đủ để bảo mật backend không?

Không. Modern forwarding giúp backend xác thực rằng dữ liệu người chơi đến từ đúng proxy, nhưng tài liệu bảo mật của Velocity nói rõ đây không phải thay thế cho firewall. Cách an toàn là kết hợp firewall (hoặc bind localhost/tunnel) cùng với forwarding.

Có thể dùng cả legacy và modern forwarding cùng lúc không?

Không. Một proxy chỉ dùng được một chế độ forwarding tại một thời điểm cho một backend. Nếu network có cả backend cũ và mới, cần lên kế hoạch thống nhất chế độ hoặc xử lý riêng theo từng backend thay vì trộn cấu hình.

Velocity có tự động chống bot không?

Không có module anti-bot chuyên sâu tích hợp sẵn, nhưng có các cơ chế rate limit cho đăng nhập, lệnh và tab-complete để giảm tải khi bị spam kết nối. Với network thường xuyên bị tấn công quy mô lớn, cần cân nhắc thêm giải pháp chuyên dụng ở tầng mạng hoặc plugin proxy phù hợp.

Proxy chạy tốt nhưng backend vẫn lag, phải sửa ở đâu?

Sửa ở backend. Proxy chỉ định tuyến kết nối, không xử lý tick world hay entity. Nếu MSPT ở Paper cao, cần profiling bằng Spark và xử lý đúng nguyên nhân ở tầng Paper thay vì tiếp tục chỉnh Velocity.

Nguồn tham khảo

• Velocity - Tuning

• Velocity - Configuring Velocity

• Velocity - Securing your servers

• Velocity - Configuring player information forwarding

• Velocity - Frequently asked questions

• Velocity - Getting started

• Velocity Downloads - PaperMC

• Velocity default configuration - GitHub