Nên chọn Proxy nào khi chạy server Minecraft? So sánh Velocity, Waterfall và BungeeCord

Khi một server Minecraft có Lobby, Survival, Skyblock hoặc Minigame, người chơi thường không kết nối thẳng vào từng server con. Họ đi qua một lớp trung gian gọi là Proxy. Proxy nhận kết nối ở địa chỉ công khai, xác thực người chơi rồi chuyển họ tới Backend phù hợp.

Ba cái tên thường xuất hiện trong các bài hướng dẫn là Velocity, Waterfall và BungeeCord. Vấn đề là nhiều bài vẫn dùng cấu hình cũ, trong khi tình trạng bảo trì và cơ chế forwarding của các dự án đã thay đổi. Chọn proxy không chỉ là chọn phần mềm “nhẹ” hơn; bạn còn phải xét phiên bản Minecraft, plugin, server modded, cách bảo vệ backend và kế hoạch nâng cấp về sau.

Tóm tắt nhanh

Nếu bạn bắt đầu một network mới vào thời điểm hiện tại, câu trả lời thực tế thường là Velocity. BungeeCord chỉ hợp lý khi bạn đang duy trì một hệ thống cũ có phụ thuộc plugin hoặc API chưa thể thay thế. Waterfall nên được xem là điểm cần di chuyển, không phải nền tảng cho dự án mới.

Proxy Minecraft thực sự làm gì?

Proxy hoạt động ở lớp kết nối giữa người chơi và các server Minecraft phía sau:

Người chơi
    |
    v
Public Proxy (Velocity/BungeeCord)
    |
    +--> Lobby
    +--> Survival / SMP
    +--> Skyblock
    +--> Minigame

Proxy có thể giữ kết nối khi người chơi chuyển server, gửi lệnh chuyển tuyến, xử lý tab list, plugin messaging và một số thông tin phiên. Nhờ vậy, bạn có thể dùng một địa chỉ cho cả network thay vì yêu cầu người chơi nhớ nhiều IP.

Proxy không thay thế server game. Nó không tự làm chunk tick nhanh hơn, không biến CPU yếu thành CPU mạnh và không chữa được plugin gây lag ở Paper. Một proxy còn thêm một thành phần mới cần cập nhật, giám sát và bảo mật. Với một server duy nhất, lợi ích thường không bù được độ phức tạp này.

Velocity, BungeeCord và Waterfall khác nhau thế nào?

Velocity - lựa chọn mặc định cho network mới

Là proxy do hệ sinh thái PaperMC phát triển. Tài liệu của dự án mô tả đây là proxy có khả năng mở rộng và linh hoạt; PaperMC cũng hướng người dùng Waterfall sang Velocity.

Các điểm đáng chú ý:

• Modern forwarding: có thể chuyển UUID, tên, skin và địa chỉ người chơi tới backend theo định dạng an toàn hơn legacy BungeeCord forwarding.

• Tài liệu được cập nhật: có hướng dẫn riêng cho cài đặt, tương thích server, bảo mật, migration và phát triển plugin.

• TOML dễ kiểm tra: cấu hình chính nằm trong velocity.toml, thuận tiện để review và quản lý bằng Git.

• Tương thích rộng: tài liệu hiện hành ghi nhận nhiều server từ Minecraft 1.7.2 tới nhánh mới nhất mà tài liệu đang hỗ trợ, nhưng từng backend vẫn phải được kiểm thử thực tế.

• API riêng: plugin Velocity có API khác BungeeCord. Nhiều plugin hỗ trợ cả hai, nhưng không nên giả định mọi plugin Bungee đều chạy nguyên trạng.

Velocity không phải lúc nào cũng là lựa chọn ít công việc nhất. Nếu bạn có một network cũ với hàng chục plugin chỉ viết cho BungeeCord, quá trình migration cần lập danh sách tương thích và kiểm tra staging trước khi đổi proxy.

BungeeCord - phù hợp cho hệ thống cũ hoặc yêu cầu tương thích cụ thể

Là proxy lâu đời, được SpigotMC duy trì. Hệ sinh thái plugin và bài hướng dẫn của nó rất lớn, đặc biệt trong các network đã vận hành nhiều năm.

Bạn có thể cân nhắc giữ khi:

• plugin quan trọng chỉ hỗ trợ BungeeCord;

• network đang ổn định và chưa có kế hoạch nâng cấp backend;

• đội vận hành đã có quy trình firewall, forwarding và backup rõ ràng;

• chi phí migration hiện tại lớn hơn lợi ích nhận được.

Tuy vậy, đừng chọn BungeeCord cho network mới chỉ vì thấy nhiều tutorial cũ hơn. Cấu hình legacy forwarding dễ bị sao chép thiếu bước bảo vệ backend. Ngoài ra, việc phụ thuộc API cũ khiến các lần nâng cấp sau này khó hơn.

BungeeCord không tự bảo vệ server con. Vì backend thường phải chạy online-mode=false để nhận kết nối từ proxy, người khác có thể giả mạo người chơi nếu họ truy cập thẳng vào cổng backend. Firewall, bind vào localhost hoặc tunnel riêng là phần bắt buộc, không phải tùy chọn.

Waterfall - không nên dùng cho triển khai mới

Từng là fork tối ưu và tương thích của BungeeCord trong hệ sinh thái PaperMC. Tuy nhiên, trang phần mềm chính thức của PaperMC hiện ghi rõ:

• Waterfall đã end of life;

• dự án không còn được duy trì hoặc hỗ trợ;

• người dùng được khuyến nghị chuyển sang Velocity.

Một network đang chạy Waterfall có thể tiếp tục hoạt động trong thời gian ngắn, nhưng cần coi đó là một hệ thống legacy. Hãy khóa phiên bản, sao lưu cấu hình, kiểm tra plugin và chuẩn bị migration. Không nên dựng network mới trên các build Waterfall đã lưu trữ chỉ vì chúng vẫn tải được.

Các fork bên thứ ba thì sao?

Các fork như FlameCord hoặc những bản build được quảng cáo là “anti-bot/performance proxy” có thể có tính năng riêng, nhưng chúng làm tăng rủi ro chuỗi cung ứng và phụ thuộc vào một nhóm bảo trì khác. Chỉ dùng khi bạn có lý do kỹ thuật cụ thể, đọc được mã nguồn hoặc có kênh phát hành đáng tin cậy, và đã kiểm thử với network của mình.

Đừng cài một fork không rõ nguồn chỉ để lấy vài flag tối ưu được sao chép từ Internet. Proxy nằm ở điểm nhận toàn bộ kết nối, nên yêu cầu về độ tin cậy cao hơn một plugin thông thường.

Chọn proxy theo mô hình server

Một server Paper/Purpur duy nhất

Không dùng proxy là phương án hợp lý nhất. Cho người chơi kết nối thẳng vào server và giữ online-mode=true để Mojang/Microsoft xác thực danh tính. Việc tắt xác thực không phải một công tắc “cho tài khoản crack” vô hại: nó đòi hỏi kiến trúc xác thực và bảo mật riêng, đồng thời tuyệt đối không được để backend lộ ra Internet vì có thể dẫn tới giả mạo danh tính. Bạn chỉ cần proxy khi có mục tiêu rõ ràng như nhiều backend, lobby, chuyển server không ngắt kết nối hoặc tách lớp mạng.

Network mới: lobby + SMP

Chọn Velocity làm điểm bắt đầu. Mô hình tối thiểu có thể là:

Internet
   |
   +--> Velocity :25565 (public)
           |
           +--> Paper Lobby :25566 (private)
           +--> Leaf SMP   :25567 (private)

Tất cả backend nên nằm sau firewall và chỉ nhận kết nối từ proxy. Nếu proxy và backend ở cùng máy vật lý, bind backend vào 127.0.0.1 là cách đơn giản. Nếu tách sang nhiều máy, dùng firewall theo IP nguồn hoặc một tunnel/VPN như WireGuard.

Network cũ đang dùng BungeeCord

Không cần đổi ngay trong lúc server đang đông người chơi. Trước tiên hãy kiểm kê:

1. plugin ở proxy và plugin ở từng backend;

2. plugin messaging, lệnh chuyển server, tab list, chat và quyền;

3. phiên bản Minecraft và loader của các server modded;

4. cách forwarding IP/UUID/skin hiện tại;

5. rule firewall và quy trình rollback.

Sau đó, dựng một Velocity staging với một bản sao lobby và SMP. Nếu plugin quan trọng có bản Velocity chính thức, chuyển từng nhóm chức năng và đo lại. Có thể giữ BungeeCord trong giai đoạn ngắn để giảm rủi ro, nhưng nên đặt mốc kết thúc thay vì duy trì song song vô thời hạn.

Server modded - kiểm tra tương thích trước khi mua gói

Proxy không làm hai modpack khác nhau “tự nhiên tương thích”. Với Fabric, thường cần mod hỗ trợ forwarding như FabricProxy-Lite; một số nội dung mod có thể cần CrossStitch. Với Forge, cách hỗ trợ phụ thuộc phiên bản và có thể cần ProxyCompatibleForge, SpongeForge hoặc giải pháp riêng.

Hãy kiểm tra cả ba lớp:

• client: người chơi đang dùng phiên bản và modpack nào;

• proxy: Velocity/Bungee có nhận đúng handshake hay không;

• backend: loader và mod có hiểu thông tin người chơi được forward hay không.

Đặc biệt, các server Forge rất cũ hoặc mod thêm packet riêng thường cần bài test riêng. Không lấy kết quả của một server Paper để kết luận proxy sẽ chạy được với mọi modpack.

Java kết hợp Bedrock

Geyser cho phép người chơi Bedrock kết nối vào server Java, còn Floodgate hỗ trợ nhận diện người chơi Bedrock theo mô hình tương ứng. Trong network nhiều backend, Geyser có thể đặt ở proxy hoặc backend tùy kiến trúc và hướng dẫn phiên bản.

Velocity thường là nền tảng phù hợp để bắt đầu, nhưng hãy kiểm tra:

• Bedrock có chuyển lobby/SMP đúng không;

• skin, chat, form và lệnh có hoạt động ở từng backend không;

• plugin permission, anti-cheat và voice chat có hiểu người chơi Bedrock không;

• forwarding secret và hostname có nhất quán giữa proxy với backend không.

Forwarding và bảo mật - phần không được bỏ qua

Ưu tiên modern forwarding khi backend hỗ trợ

Velocity hỗ trợ ba kiểu forwarding phổ biến:

• Velocity modern forwarding: an toàn hơn và phù hợp với Paper hiện đại;

• BungeeCord/legacy forwarding: tương thích rộng hơn với hệ thống cũ nhưng kém an toàn hơn nếu dùng riêng lẻ;

• BungeeGuard: bổ sung secret cho kiểu legacy, tốt hơn legacy thuần nhưng vẫn không thay thế modern forwarding.

Chỉ chọn một kiểu forwarding cho một proxy/backend; không trộn các kiểu một cách tùy ý. Paper 1.13.2 trở lên thường có thể dùng modern forwarding, còn backend cũ có thể buộc phải dùng legacy. Hãy theo đúng tài liệu của proxy và server đúng phiên bản, vì tên mục cấu hình có thể thay đổi.

Checklist bảo mật tối thiểu

1. Proxy là cổng duy nhất public; backend không mở toàn Internet.

2. Dùng firewall để chỉ cho phép IP proxy tới cổng backend.

3. Nếu cùng máy, bind backend vào 127.0.0.1 khi kiến trúc cho phép.

4. Nếu khác máy, dùng firewall hoặc tunnel mã hóa thay vì mở cổng backend cho mọi nơi.

5. Giữ forwarding secret ngoài Git public và thay secret khi nghi ngờ bị lộ.

6. Không tin vào thông báo “IP forwarding enabled” như một cơ chế bảo vệ độc lập.

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

8. Test kết nối trực tiếp vào backend từ một máy bên ngoài sau khi cấu hình firewall.

Nếu bỏ qua các bước này, người lạ có thể truy cập backend với tên người chơi tùy ý, bypass permission hoặc chiếm tài khoản trong server offline-mode. Đây là rủi ro xác thực, không chỉ là lỗi hiển thị IP.

Proxy cần bao nhiêu tài nguyên?

Proxy thường nhẹ hơn backend Paper vì không tick world, entity hay redstone. Tuy nhiên, mức dùng thực tế tăng theo số kết nối đồng thời, plugin proxy, chuyển đổi protocol, Geyser, anti-bot và log.

Đừng chọn gói chỉ dựa vào số slot quảng cáo. Hãy bắt đầu bằng cấu hình có dư địa và đo trong giờ cao điểm:

Đây là mốc khởi đầu, không phải định mức cố định. Một proxy không cần nhiều RAM chỉ vì backend cần 16 GB; hai tiến trình có workload khác nhau. Ngược lại, cài quá nhiều plugin vào proxy có thể biến lớp định tuyến thành một backend thứ hai khó kiểm soát.

Một proxy duy nhất cũng là single point of failure. Khi network đã có doanh thu hoặc lượng người chơi lớn, có thể chạy hai proxy và đặt load balancer/DNS phù hợp. Nhưng HA chỉ đáng làm sau khi forwarding, session, plugin messaging và trạng thái người chơi đã được thiết kế rõ; thêm proxy thứ hai không tự giải quyết lỗi cấu hình.

Protocol và nhiều phiên bản Minecraft

Velocity không tự dịch mọi phiên bản client và backend. Nếu muốn người chơi dùng nhiều phiên bản, bạn có thể cần nhóm plugin ViaVersion/ViaBackwards ở vị trí phù hợp với kiến trúc. Hãy kiểm tra tài liệu của chính plugin và chạy thử các luồng:

• client cũ vào lobby mới;

• client mới vào SMP cũ;

• chuyển server sau khi đã đăng nhập;

• tab list, chat, boss bar, resource pack và lệnh;

• plugin có packet riêng hoặc anti-cheat.

Đối với modded server, protocol translation càng dễ phát sinh lỗi vì mod có thể thêm packet và trạng thái client riêng. Chỉ công bố dải phiên bản sau khi đã test bằng client thật, không chỉ nhìn vào dòng “supported versions” trên trang tải plugin.

Quy trình chọn và triển khai proxy

Bước 1: viết rõ yêu cầu

Ghi lại số backend, phiên bản Minecraft, loại server (Paper, Fabric, Forge), số người chơi cao điểm, Bedrock có cần không, plugin bắt buộc và vị trí đặt máy. Nếu chỉ có một backend và không cần chuyển server, dừng ở đây: bạn chưa cần proxy.

Bước 2: kiểm tra tương thích trước khi chọn phần mềm

Tìm trang hỗ trợ của từng plugin, không chỉ nhìn tên proxy. Đối với plugin Bungee, xác định nó dùng API nào, có bản Velocity chính thức hay có lớp tương thích hay không. Với modded, đọc hướng dẫn forwarding đúng loader và phiên bản.

Bước 3: chọn forwarding và khóa đường vào backend

Ưu tiên modern forwarding khi Paper/backend hỗ trợ. Sau đó cấu hình firewall, bind hoặc tunnel. Hãy làm bảo mật trước khi mời người chơi vào test, bởi việc sửa sau khi đã lộ cổng backend phức tạp hơn nhiều.

Bước 4: dựng staging và đo các luồng quan trọng

Test đăng nhập, đăng xuất, chuyển lobby/SMP, reconnect khi backend restart, permission, chat, tab, resource pack, server list, ViaVersion và Geyser nếu có. Thử cả trường hợp backend không sẵn sàng để xem fallback và thông báo lỗi có hợp lý không.

Bước 5: triển khai có rollback

Sao lưu velocity.toml hoặc cấu hình Bungee, secret, plugin list và rule firewall. Chọn khung giờ ít người chơi, ghi lại phiên bản JAR, giữ proxy cũ để rollback nhanh và thông báo trước nếu có gián đoạn.

Ma trận lỗi thường gặp

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

Velocity có nhanh hơn BungeeCord không?

Không nên chọn chỉ dựa trên một con số benchmark. Proxy thường không phải nút thắt chính của một network nhỏ; độ ổn định, plugin tương thích, forwarding và chất lượng hạ tầng quan trọng hơn khác biệt nhỏ về throughput. Velocity là lựa chọn mặc định tốt cho network mới vì hướng phát triển và tài liệu hiện tại, không phải vì nó chữa được mọi loại lag.

Tôi đang dùng Waterfall, có cần chuyển ngay không?

Không nhất thiết phải chuyển giữa giờ cao điểm. Nhưng Waterfall đã EOL nên bạn nên lập kế hoạch migration, khóa phiên bản hiện tại và thử Velocity trên staging. Càng nhiều plugin cũ và backend cũ, chi phí trì hoãn càng tăng.

Có thể dùng Velocity với Paper, Fabric và Forge cùng lúc không?

Có thể trong nhiều mô hình, nhưng cách forwarding và mức tương thích khác nhau. Paper hiện đại thường dễ nhất; Fabric và Forge có thể cần mod hoặc plugin hỗ trợ. Hãy kiểm tra theo phiên bản thay vì coi mọi server Minecraft là tương đương.

Có cần chạy proxy trên máy riêng không?

Không bắt buộc. Network nhỏ có thể chạy proxy và backend trên cùng máy nếu CPU, RAM, mạng và firewall được phân bổ rõ. Tách máy giúp cô lập lỗi và dễ mở rộng, nhưng thêm chi phí, độ trễ và một đường mạng cần giám sát.

Proxy có giúp giảm lag cho SMP không?

Thông thường là không. Proxy chỉ định tuyến kết nối. Nếu MSPT cao do chunk generation, entity, plugin hoặc CPU main thread, hãy profiling backend Paper và xử lý bottleneck ở đó. Proxy thậm chí có thể làm việc chẩn đoán khó hơn nếu bạn không biết log nằm ở lớp nào.

Java nào cần cho Velocity?

Yêu cầu Java thay đổi theo phiên bản proxy. Tài liệu PaperMC hiện ghi Velocity yêu cầu ít nhất Java 25; hãy kiểm tra trang Getting Started và thông báo của build bạn tải trước khi cài. Không nên chép nguyên startup flags từ một bài cũ mà không xác nhận Java tương ứng.

Kết luận: chọn theo tương lai của network

• Một server: không dùng proxy nếu chưa có nhu cầu chuyển tuyến.

• Network mới: chọn Velocity, dùng modern forwarding khi backend hỗ trợ và khóa backend sau firewall.

• Network BungeeCord cũ: giữ BungeeCord trong giai đoạn chuyển tiếp nếu cần, nhưng kiểm kê plugin và lập kế hoạch sang Velocity.

• Waterfall: không dùng cho triển khai mới; dự án đã end of life.

• Modded hoặc Java + Bedrock: đọc tài liệu loader/Geyser, dựng staging và test handshake trước khi mở public.

Proxy tốt là proxy phù hợp với phiên bản, plugin và mô hình vận hành của bạn. Khi lựa chọn có bằng chứng từ workload thật, việc nâng cấp backend, thêm lobby hay mở rộng network sẽ ít rủi ro hơn nhiều so với sao chép một file config từ tutorial cũ.

Tài liệu tham khảo

• Velocity Documentation - PaperMC: cài đặt, cấu hình và phát triển plugin.

• Velocity - Server compatibility: các server Vanilla, Paper, Fabric, Forge và phiên bản được hỗ trợ.

• Velocity - Configuring player information forwarding: modern forwarding, legacy forwarding và cấu hình backend.

• Velocity - Securing your servers: firewall, localhost, tunnel và các lưu ý bảo mật.

• Waterfall trên PaperMC: thông báo Waterfall đã end of life và khuyến nghị chuyển sang Velocity.

• BungeeCord trên GitHub: mã nguồn và cảnh báo bảo mật của BungeeCord.

• GeyserMC Wiki - Setup: hướng dẫn triển khai Geyser và các mô hình host.