BungeeCord-ის დაყენება: jar, config.yml და backend-ები

BungeeCord-ის დაყენება ოთხი ნაბიჯია: ჩამოტვირთე BungeeCord.jar md_5-ის build სერვერიდან, ერთხელ გაუშვი, რომ config.yml შექმნას, ამ ფაილში მიუთითე შენი backend სერვერები და თითოეულ backend-ზე შეცვალე სამი პარამეტრი, რომ მან მოთამაშეები მხოლოდ proxy-ის გავლით მიიღოს და სხვა არავინ. პირველი სამი ნაბიჯი ათ წუთს მოითხოვს. მეოთხეზე იშლება ქსელები, რადგან BungeeCord-ის backend ენდობა ნებისმიერ იდენტობას, რომელსაც კავშირი საკუთარ თავზე ამბობს. ამიტომ ის ან ინტერნეტიდან მიუწვდომელი უნდა იყოს, ან BungeeGuard-ით დაცული.

სანამ დაიწყებ, ერთი გულწრფელი შენიშვნა. ახალი ქსელისთვის უკეთესი proxy Velocity-ა: ის უფრო სწრაფია, მას PaperMC ინახავს და მისი modern forwarding backend-ებს firewall-ის გარეშეც იცავს. BungeeCord vs Velocity განსხვავებას განმარტავს, Velocity ქსელის გზამკვლევი კი იმ გზის დაყენებაა. BungeeCord ჯერ კიდევ მხარდაჭერილია, ბევრგანაა გაშვებული და სწორი არჩევანია, როცა შენთვის საჭირო plugin მხოლოდ მასზე არსებობს. თუ ეს შენი შემთხვევაა, აი სწორად გაკეთებული დაყენება.

რას აკეთებს BungeeCord და რას არა#

BungeeCord proxy-ა, რომელიც Minecraft-ის პროტოკოლზე მუშაობს. მოთამაშეები მას უკავშირდებიან, ის Mojang-თან ერთხელ ახდენს მათ ავტორიზაციას, შემდეგ საკუთარ კავშირს ხსნის backend სერვერთან და პაკეტებს ორივე მიმართულებით გადასცემს. როცა წერ /server survival, proxy ლობის კავშირს წყვეტს და survival-თან ხსნის, მოთამაშის საკუთარი კავშირი კი ცოცხალი რჩება. მთელი ხრიკი ესაა: რამდენიმე ცალკე Minecraft სერვერი, ერთი მისამართი და მათ შორის გადასვლისას გათიშვა არ ხდება.

ის არ ინახავს სამყაროს, არ ატარებს entity-ების tick-ს და არ უშვებს Bukkit plugin-ებს. აქედან სამი შედეგი მოდის, რომლებსაც ადამიანები გამოცდილებით აღმოაჩენენ:

• Plugin-ები არ გადადის. Paper და Spigot plugin-ები backend-ებზე იდება. proxy-ის plugins საქაღალდეში მხოლოდ BungeeCord plugin-ები იდება - ისინი, რომლებიც BungeeCord API-ზეა აგებული.
• მოთამაშის მონაცემები თითო backend-ზეა. ინვენტარი, სახლები, ბალანსები და ops.json თითოეულ backend-ზე ცალ-ცალკე ინახება. proxy მათგან არაფერს ინახავს.
• ვერსიებს არ თარგმნის. კლიენტი და backend, რომელზეც ის მოხვდება, ერთი და იმავე პროტოკოლით უნდა მუშაობდეს. BungeeCord თავის შესასვლელთან კლიენტის ვერსიების ფართო სპექტრს იღებს, მაგრამ 1.21 კლიენტი მაინც ვერ ითამაშებს 1.20 backend-ზე, თუ ჯაჭვში სადმე ViaVersion არ დგას.

ის ასევე არ აჩქარებს ჩაჭედილ სამყაროს. თუ ერთი survival სამყარო იტანჯება, proxy ამატებს ერთ ნახტომს და სხვა არაფერს ცვლის. proxy რამდენიმე განსხვავებული სერვერისთვისაა, რომლებიც ერთი სახელის ქვეშაა.

მოთხოვნები და ზომა#

proxy მსუბუქია. ის CPU-ს compression-სა და დაშიფვრაზე ხარჯავს, მეხსიერებას კი სხვაზე თითქმის არაფერზე.

გამოიყენე ახალი Java. jar ისტორიულად უმოთხოვნო იყო, მაგრამ ბოლო build-ები თანამედროვე Java-ს მისდევს, და რადგან შენს Paper backend-ებს მიმდინარე Minecraft ვერსიებისთვის მაინც Java 21 სჭირდება, proxy-ზეც Java 21 გამოიყენე და ერთი runtime გეყოს გასახსენებლად. Minecraft JVM flags და Java ვერსიები განმარტავს, რომელი Java რომელ თამაშის ვერსიას ერგება.

ფული backend-ებზე მიდის. proxy-ის, ლობისა და ორი რეჟიმისგან შემდგარი ქსელი ოთხი პროცესია, თითოეულს საკუთარი მეხსიერების ლიმიტით, და ლობი backend-ებს შორის ყველაზე პატარა უნდა იყოს, რადგან თითქმის არაფერს ასიმულირებს.

ოფიციალური BungeeCord.jar-ის ჩამოტვირთვა#

BungeeCord-ს ერთი ოფიციალური წყარო აქვს: md_5-ის Jenkins build სერვერი მისამართზე ci.md-5.net, რომელზეც SpigotMC-ის საიტი უთითებს. ფაილს ჰქვია BungeeCord.jar, ბოლო წარმატებული build კი ყოველთვის მუდმივ მისამართზეა:

$ mkdir -p ~/network/proxy && cd ~/network/proxy$ wget -O BungeeCord.jar \    https://ci.md-5.net/job/BungeeCord/lastSuccessfulBuild/artifact/bootstrap/target/BungeeCord.jar

არც installer არსებობს და არც BuildTools ნაბიჯი - Spigot-ისგან განსხვავებით, proxy jar გაშვებისთვის მზადაა. მოერიდე "BungeeCord download" მირორებს შემთხვევით hosting საიტებზე. ზოგი უბრალოდ მოძველებულია, ზოგმა შეცვლილი jar-ები გაავრცელა. თუ რომელიმე გვერდი გთავაზობს BungeeCord jar-ს ფაილის სახელში ვერსიის ნომრით, ის md_5-ისგან არ მოდის.

Waterfall, fork, რომელიც ძველ გაკვეთილებში ჯერ კიდევ რეკომენდებულია, აღარ ვითარდება. ახალი ქსელი მასზე ნუ დაიწყებ.

პირველი გაშვება და ფაილები, რომლებსაც ქმნის#

გაუშვი proxy ერთხელ პატარა heap-ით:

$ java -Xms512M -Xmx512M -jar BungeeCord.jar

ის თავის ფაილებს ქმნის, თავის ნაგულისხმევ პორტს იკავებს და ელოდება. სუფთად გასაჩერებლად კონსოლში ჩაწერე end. ახლა გაქვს:

გენერირებულ ფაილში ორი ნაგულისხმევი მნიშვნელობა თითქმის ყველას ებმება. listener პორტ 25577-ს იკავებს და არა 25565-ს, ხოლო მაგალითად მოცემული server ჩანაწერი localhost:25565-ზე მიუთითებს. ეს განლაგება ვარაუდობს, რომ არსებულ Minecraft სერვერს 25565-იდან გადაიტან და proxy-ს მის წინ სხვა პორტზე დააყენებ - უმეტესობას საპირისპირო უნდა, ამიტომ ორივე შეცვალე. listener-ზე ნაგულისხმევი max_players არის 1, რაც მხოლოდ სერვერების სიაში ნაჩვენებ რიცხვზე მოქმედებს, მაგრამ მუშა ქსელს გაფუჭებულად აჩენს.

config.yml, გასაღები გასაღებზე#

ეს სრული, მუშა კონფიგურაციაა proxy-ისთვის, რომელსაც ერთსა და იმავე მანქანაზე სამი backend აქვს. კომენტარები აღნიშნავს გასაღებებს, რომლებიც აუცილებლად უნდა შეცვალო.

online_mode: trueip_forward: truenetwork_compression_threshold: 256connection_throttle: 4000connection_throttle_limit: 3player_limit: -1timeout: 30000log_commands: falselog_pings: falseprevent_proxy_connections: falselisteners:- host: 0.0.0.0:25565  motd: '&bThe Longhouse Network'  max_players: 200  tab_list: GLOBAL_PING  tab_size: 60  force_default_server: true  priorities:  - lobby  forced_hosts:    survival.example.com: survival  ping_passthrough: false  query_enabled: false  query_port: 25565  proxy_protocol: false  bind_local_address: trueservers:  lobby:    address: 127.0.0.1:25566    motd: 'Lobby'    restricted: false  survival:    address: 127.0.0.1:25567    motd: 'Survival'    restricted: false  creative:    address: 127.0.0.1:25568    motd: 'Creative'    restricted: false

listener ბლოკი

listeners სიაა და თითქმის ყველა ქსელს ზუსტად ერთი ჩანაწერი აქვს.

• host არის მისამართი და პორტი, რომელსაც proxy იკავებს. 0.0.0.0:25565 ნიშნავს ყველა interface-ს სტანდარტულ პორტზე. panel hosting-ზე ის უნდა ემთხვეოდეს შენთვის გამოყოფილ allocation-ს.
• motd და max_players არის ის, რასაც სერვერების სია აჩვენებს. ფერის კოდები &-ს იყენებს.
• priorities არის სერვერების დალაგებული სია, რომლებზეც მოთამაშეს შესვლისას რიგით ცდის. პირველი, რომელიც მას მიიღებს, იმარჯვებს. აქ ყველა სახელი servers-ში უნდა არსებობდეს, იდენტურად დაწერილი, თორემ მოთამაშეები მიიღებენ fallback შეცდომას, რომელიც პრობლემების გადაჭრის განყოფილებაშია.
• force_default_server: true ყოველ შესვლაზე ყველა მოთამაშეს პირველ priority სერვერზე აგზავნის. false-ის შემთხვევაში BungeeCord-ის reconnect მოდული მათ იმ სერვერზე აბრუნებს, სადაც ბოლოს იყვნენ - ეს survival-ზე ორიენტირებული ქსელისთვის გინდა და არა ლობიზე ორიენტირებულისთვის.
• forced_hosts აკავშირებს მოთამაშის აკრეფილ hostname-ს სერვერთან, ამიტომ survival.example.com ლობის გვერდს უვლის. თითოეულ hostname-ს DNS სჭირდება, რომელიც proxy-ზე მიუთითებს.
• ping_passthrough: true სიაში proxy-ის საკუთარი MOTD-ისა და მოთამაშეთა რაოდენობის ნაცვლად backend-ისას აჩვენებს. დატოვე false, თუ მიზეზი არ გაქვს.
• tab_list არის GLOBAL_PING, GLOBAL ან SERVER. SERVER თითოეულ backend-ს საკუთარი tab სიის მართვას აძლევს, რასაც backend-ებზე არსებული tab plugin-ები ელიან.
• proxy_protocol: true მხოლოდ მაშინაა საჭირო, როცა BungeeCord-ის წინ HAProxy ან TCP load balancer დგას და PROXY protocol header-ებს აგზავნის. თუ ამის გარეშე ჩართავ, ყველა კავშირი ჩავარდება.

გლობალური გასაღებები

• online_mode: true - proxy მოთამაშეებს Mojang-ით ავტორიზებს. დატოვე ჩართული. გამორთვა ქმნის cracked ქსელს, სადაც ნებისმიერს შეუძლია ნებისმიერად შემოვიდეს.
• ip_forward: true - backend-ებს გადასცემს თითოეული მოთამაშის რეალურ IP-ს, UUID-სა და skin-ს. ნაგულისხმევად გამორთულია და გამორთულის შემთხვევაში ყველა მოთამაშე backend-ებზე proxy-ის მისამართითა და offline-mode UUID-ით ჩნდება. ჩართე; ის მომდევნო განყოფილების backend პარამეტრთან წყვილდება.
• network_compression_threshold: 256 - ამაზე დიდი პაკეტები იკუმშება. ნაგულისხმევი მნიშვნელობა მოთამაშეებთან ტრაფიკისთვის სწორია.
• connection_throttle და connection_throttle_limit - რამდენჯერ შეიძლება ერთმა IP-მ შესვლა ფანჯრის განმავლობაში, მილიწამებში. გაზარდე ლიმიტი, თუ ბევრი მოთამაშე ერთ მისამართს იზიარებს, მაგალითად სკოლა ან LAN party.
• player_limit: -1 - მთელ proxy-ზე მკაცრი ლიმიტი, -1 ნიშნავს ლიმიტის გარეშე. განსხვავდება max_players-ისგან, რომელიც მხოლოდ ნაჩვენები რიცხვია.
• timeout: 30000 - მილიწამები, რომლის შემდეგაც არამპასუხობადი კავშირი წყდება.

servers ბლოკი

თითოეული ჩანაწერი არის სახელი, address და restricted დროშა. სახელს იყენებს /server <name> და priorities, ასევე backend-ებზე არსებული plugin-ები, როცა მოთამაშეებს აგზავნიან, ამიტომ აირჩიე მოკლე, პატარა ასოებით დაწერილი სახელები და ისინი უყურადღებოდ ნუ გადაარქმევ. restricted: true ნიშნავს, რომ მოთამაშეს დასაკავშირებლად bungeecord.server.<name> უფლება სჭირდება - გამოსადეგია მხოლოდ პერსონალისთვის განკუთვნილი build სერვერისთვის.

Query და ჩაშენებული უფლებები

query_enabled რთავს GameSpy4 query პროტოკოლს, რომელსაც ზოგი სერვერების სიის საიტი და status bot იყენებს, UDP query_port-ზე. უმეტესი ქსელი მას გამორთულს ტოვებს. თუ ჩართავ, პორტი UDP-ა და ფიქსირებული allocation-ების მქონე host-ზე ისეთი უნდა იყოს, რომელიც ნამდვილად გაქვს - თამაშის სერვერის პორტები განმარტებული განმარტავს, რატომ არსებობს query პორტები.

გენერირებული ფაილი ასევე შეიცავს groups ბლოკს, სადაც md_5 მაგალითად მოცემული ადმინია, და permissions ბლოკს, რომელიც default ჯგუფს აძლევს /server-სა და /glist-ს. ეს პატარა ჩაშენებული სისტემა მუშაობს, მაგრამ რანგებზე არაფერი იცის. წაშალე md_5-ის ჩანაწერი, თუ გინდა, admin-ში საკუთარი მომხმარებლის სახელი დაამატე და მოემზადე, რომ proxy-ზე LuckPerms-ით ჩაანაცვლო - LuckPerms-ის გზამკვლევი აჩვენებს, როგორ შეზღუდო proxy-ის უფლებები server კონტექსტით.

რა უნდა შეცვალო ყველა backend-ზე#

თითოეული backend ჩვეულებრივი Spigot ან Paper სერვერია. სამი ფაილი იცვლება.

server-ip=127.0.0.1server-port=25566online-mode=false

settings:  bungeecord: true

settings:  connection-throttle: -1

რატომ თითოეული:

• online-mode=false აუცილებელია. proxy-მ მოთამაშე უკვე დაავტორიზა; online რეჟიმში მყოფი backend ამას ხელახლა სცდიდა და proxy უარს ამბობს შეტყობინებით Server is online mode!.
• bungeecord: true spigot.yml-ში backend-ს აიძულებს, წაიკითხოს გადაცემული IP და UUID, რასაც ip_forward აგზავნის. მის გარეშე მოთამაშეები offline-mode UUID-ებს იღებენ და მონაცემებს კარგავენ იმ წუთას, როცა მოგვიანებით ამას გაასწორებ.
• connection-throttle: -1 bukkit.yml-ში backend-ს აჩერებს შესვლების შეზღუდვისგან. ყველა შესვლა proxy-ის მისამართიდან მოდის, ამიტომ backend-ის საკუთარი throttle დატვირთულ მომენტებში კანონიერ მოთამაშეებს "Connection throttled" შეტყობინებით გამოაგდებდა.

Paper-ზე ასევე შეამოწმე config/paper-global.yml (ან paper.yml 1.19-მდე): proxies.bungee-cord.online-mode უნდა იყოს true, რაც Paper-ს ეუბნება, რომ proxy-ით მოსული იდენტობები დადასტურებულია. plugin-ები, რომლებსაც premium ანგარიშები აინტერესებთ, ამას კითხულობენ.

თითოეულ backend-ს საკუთარი პორტი სჭირდება და ყველა backend იმავე Minecraft ვერსიაზე უნდა მუშაობდეს, რომელზეც კლიენტები, ან ViaVersion უნდა ჰქონდეს. ამ ცვლილებების შემდეგ backend-ები გადატვირთე; spigot.yml ცოცხლად არ ახლდება. server.properties განმარტებული განიხილავს სხვა პარამეტრებს, რომლებიც ლობიზე ღირს შემცირებად, მაგალითად view-distance და spawn-protection.

backend-ების firewall#

აი რატომაა ეს მნიშვნელოვანი. backend, რომელსაც აქვს online-mode=false და bungeecord: true, თვლის, რომ ნებისმიერი handshake, რომელიც გადაცემულ მონაცემებს ამტკიცებს, ჭეშმარიტია. ვისაც მისი პორტის მიღწევა შეუძლია, შეუძლია შეიქმნას handshake, რომელიც ამბობს, რომ ისინი შენი ოპერატორია, და backend მათ ამ მოთამაშის UUID-ით, უფლებებითა და ინვენტარით შეუშვებს. საჯარო ხელსაწყოები ზუსტად ამას აკეთებენ და scanner-ები ღია backend-ებს სწრაფად პოულობენ.

ხვრელის დახურვის სამი გზა არსებობს, სიძლიერის მიხედვით.

1. localhost-ზე მიბმა. როცა proxy და backend-ები ერთ მანქანაზეა, server-ip=127.0.0.1 თითოეულ backend-ზე მათ გარედან მიუწვდომელს ხდის. ეს ყველაზე მარტივი და საუკეთესო ვარიანტია და ზემოთ მოცემული მაგალითი კონფიგურაცია სწორედ მას იყენებს.
2. პორტების firewall. როცა backend-ები სხვა მანქანებზეა, მათი პორტები მხოლოდ proxy-ის მისამართიდან დაუშვი და ყველა დანარჩენი უარყავი. ქვემოთ მოცემული ufw მაგალითი ამას აკეთებს.
3. BungeeGuard. როცა firewall-ს ვერ გამოიყენებ - უმეტეს shared panel host-ზე თითოეული სერვერი ცალკე container-ია საკუთარი საჯარო პორტით - დააყენე BungeeGuard proxy-სა და ყველა backend-ზე. proxy-ის plugin ქმნის საიდუმლო token-ს და გადაცემულ მონაცემებს უმატებს; backend-ის plugin ამ token-ს თავის allowed-tokens სიაში ინახავს და მის გარეშე კავშირებს უარყოფს. ეს იგივე იდეაა, რაც Velocity-ის modern forwarding-ს, უბრალოდ მიმაგრებული.

ვარიანტ 2-ისთვის, backend-ზე, რომლის proxy 203.0.113.10-ზეა, წესების თანმიმდევრობა მნიშვნელოვანია - ufw პირველ დამთხვევას იყენებს, ამიტომ allow deny-მდე მოდის:

$ sudo ufw allow from 203.0.113.10 to any port 25566 proto tcp$ sudo ufw deny 25566/tcp

RE:NODE-ზე ყველა სერვერი, proxy იქნება თუ backend, საკუთარი container-ია საკუთარი საჯარო allocation-ით, ამიტომ სერვერებს შორის ვარიანტი 1 და ვარიანტი 2 შენთვის ხელმისაწვდომი არაა. იქ გამოსაყენებელია BungeeGuard proxy-ზე და ყველა backend-ზე, ხოლო პირდაპირი შესვლის ზემოთ აღწერილი ტესტი დაადასტურებს, რომ ის მუშაობს. რა უნდა ჩაიკეტოს, ამის უფრო ფართო სია Minecraft სერვერის უსაფრთხოების checklist-შია.

გაშვება, plugin-ები და ბრძანებები#

backend-ები პირველად გაუშვი, შემდეგ proxy. თანმიმდევრობა მკაცრად საჭირო არაა, მაგრამ proxy, რომელიც ერთი backend-ის გარეშე ირთვება, პირველ მოთამაშეებს fallback შეცდომით გამოაგდებს.

$ java -Xms512M -Xmx512M -XX:+UseG1GC -jar BungeeCord.jar

proxy plugin-ები plugins/-ში jar ფაილებად იდება და მათ ჩასატვირთად proxy უნდა გადაიტვირთოს. BungeeCord-ს აქვს /greload ბრძანება, მაგრამ ის plugin-ებს არ ტვირთავს და სერვერების სიის გარდა სხვაზე არასდროს ყოფილა საიმედო - უმეტესი ადმინი proxy-ს გადატვირთავს, რაც ყველას წყვეტს, ამიტომ ცვლილებები შეაგროვე და მშვიდ საათზე გადატვირთე. ტიპური proxy plugin-ებია LuckPerms (BungeeCord build), BungeeGuard, ViaVersion, თუ გინდა proxy-ზე, Geyser და Floodgate Bedrock მოთამაშეებისთვის (Geyser და Bedrock crossplay) და ქსელის chat ან ban plugin. შეამოწმე, რომ თითოეული ჩამოტვირთვის გვერდზე BungeeCord წერია და არა Spigot - proxy-ის საქაღალდეში Bukkit plugin გაშვებისას შეცდომით ვერ იტვირთება.

backend plugin-ები, რომლებიც მოთამაშეებს სერვერებს შორის გადაჰყავთ - selector მენიუები, ლობის ნიშნები, მინი-თამაშიდან ლობიში დაბრუნება - proxy-სთან BungeeCord plugin messaging არხით საუბრობენ. მათ proxy-ზე არაფერი სჭირდებათ დაყენებული, მაგრამ config.yml-ში სერვერის სახელები იმას უნდა ემთხვეოდეს, რაც მათში გაწერე.

როცა proxy იმუშავებს, დაადე მას hostname A ჩანაწერითა და SRV ჩანაწერით, რომ მოთამაშეებმა mc.example.com პორტის გარეშე აკრიფონ - SRV ჩანაწერები Minecraft-ისთვის ზუსტ ჩანაწერს აჩვენებს.

პირველი შეცდომების გადაჭრა#

"If you wish to use IP forwarding, please enable it in your BungeeCord config as well!" backend-ს spigot.yml-ში აქვს bungeecord: true, მაგრამ proxy არ აგზავნის. proxy-ის config.yml-ში დააყენე ip_forward: true და proxy გადატვირთე. ამას ასევე ნახავ, როცა ვინმე backend-ს პირდაპირ უკავშირდება proxy-ის გვერდის ავლით - რაც, თუ საერთოდ მუშაობს, გეუბნება, რომ backend გარედან მისაწვდომია.

"Could not connect to a default or fallback server, please try again later", ჩვეულებრივ მას მოსდევს Connection refused. proxy-მ priorities-ში ყველა სერვერი სცადა და არც ერთმა არ უპასუხა. შეამოწმე თანმიმდევრობით: backend ნამდვილად გაშვებულია თუ არა; servers-ში address ემთხვევა თუ არა backend-ის server-ip-სა და server-port-ს; priorities-ში სახელი ზუსტად ისე წერია თუ არა, როგორც გასაღები servers-ში; და, თუ backend სხვა მანქანაზეა, შენი firewall proxy-ს ატარებს თუ არა. 127.0.0.1-ზე მიბმული backend სხვა მანქანაზე მყოფი proxy-სთვის მიუწვდომელია.

`Server is online mode!` backend-ს ჯერ კიდევ აქვს online-mode=true. დააყენე false და გადატვირთე.

ყველა ახალი მოთამაშედ შემოდის ინვენტარის გარეშე. UUID-ები offline ფორმით მოდის, ანუ ან proxy-ზე ip_forward გამორთულია, ან backend-ზე bungeecord გამორთულია. გააჩერე და გაასწორე, სანამ მეტი ადამიანი ითამაშებს; ყოველი შესვლა მოთამაშის მონაცემებს ქმნის, რომლებიც მოგვიანებით უნდა გაწმინდო.

`Connection throttled! Please wait before reconnecting.` backend-იდან დატვირთულ პერიოდებში. backend-ის connection-throttle bukkit.yml-ში ჯერ კიდევ ჩართულია; დააყენე -1.

`Address already in use` გაშვებისას. listener პორტს სხვა რაღაც იკავებს, ხშირად backend, რომელიც ჯერ კიდევ 25565-ზეა მას შემდეგ, რაც proxy იქ გადაიტანე. გადაიტანე backend ან შეცვალე host.

`Outdated server!` ან `Outdated client!` კლიენტისა და backend-ის ვერსიები განსხვავდება. ყველა backend კლიენტის ვერსიაზე დატოვე ან ViaVersion დაამატე. Minecraft ვერსიების განახლება განმარტავს, რა თანმიმდევრობით განაახლო ქსელი.

მოთამაშეებს შესვლა შეუძლიათ, მაგრამ სერვერების სიაში 1 ადგილი ჩანს. ეს არის ნაგულისხმევი max_players: 1 listener-ზე. ეს მხოლოდ ვიზუალურია; შეცვალე იმ რიცხვზე, რისი ჩვენებაც გინდა.

FAQ#

სად ჩამოვტვირთო BungeeCord.jar უსაფრთხოდ?

md_5-ის Jenkins-იდან მისამართზე ci.md-5.net, BungeeCord job-ის lastSuccessfulBuild artifact-იდან, რომელზეც SpigotMC-ის საიტი უთითებს. ის გაშვებისთვის მზა jar-ად ვრცელდება BuildTools ნაბიჯის გარეშე. სხვა საიტების მირორები ზედმეტია და ზოგჯერ მოძველებული ან შეცვლილია.

ახალი ქსელისთვის BungeeCord გამოვიყენო თუ Velocity?

Velocity, თუ შენთვის საჭირო plugin მხოლოდ BungeeCord-ზე არ არსებობს. Velocity-ის modern forwarding ხელმოწერილია, ამიტომ backend-ები პირდაპირ კავშირებს firewall-ის ან BungeeGuard-ის გარეშეც უარყოფენ, და ის ბირთვზე მეტ მოთამაშეს ართმევს თავს. BungeeCord მუშაობს, მაგრამ უსაფრთხოდ გამოსაყენებლად დამატებითი დაცვა სჭირდება.

backend-ებს იგივე plugin-ები სჭირდება, რაც proxy-ს?

არა, ისინი ცალკე სამყაროებია. Bukkit, Spigot და Paper plugin-ები backend-ებზე იდება; BungeeCord plugin-ები proxy-ზე. რამდენიმე, მაგალითად LuckPerms, Floodgate და BungeeGuard, ორივე build-ს აქვეყნებს და ორივგან მუშაობს, თითოეულგან იმ build-ით, რომელიც მისთვისაა გაკეთებული.

რატომ იყენებს BungeeCord ნაგულისხმევად პორტ 25577-ს?

რადგან ვარაუდობს, რომ 25565-ზე უკვე გაქვს Minecraft სერვერი და proxy-ს გვერდით აყენებ. უმეტესი ქსელი ადგილებს უცვლის: proxy იკავებს 25565-ს, რომ მოთამაშეებს პორტი არ დასჭირდეთ, backend-ები კი სხვა პორტებზე გადადიან.

შეიძლება backend-ებზე სხვადასხვა Minecraft ვერსია იყოს?

მხოლოდ იმ შემთხვევაში, თუ ყველა კლიენტს მაინც შეუძლია იმ backend-თან საუბარი, რომელზეც მოხვდება. proxy ვერსიებს არ თარგმნის. ან ყველა backend ერთ ვერსიაზე დატოვე, ან დააყენე ViaVersion, proxy-ზე ან თითოეულ backend-ზე, მაგრამ არა ორივეგან.

offline რეჟიმი backend-ებზე საშიშია?

თავისთავად, ძალიან. ის უსაფრთხოა მხოლოდ მაშინ, როცა backend-ებამდე proxy-ის გარდა სხვა გზით ვერ მიაღწევენ: 127.0.0.1-ზე მიბმული, proxy-ის მისამართზე firewall-ით შეზღუდული ან BungeeGuard-ით დაცული. შეამოწმე backend-ზე პირდაპირ შესვლით; მან უარი უნდა გითხრას.