Prima di iniziare
Annota Java o Bedrock, versioni di client e server, indirizzo con porta e ora esatta. Conserva console e modifiche recenti. Prima di cambiare mondo, mod o file prepara una copia ripristinabile e mantieni il precedente stato separato.
Controllare edizione e indirizzo
Java e Bedrock non sono intercambiabili: normalmente Java usa TCP e Bedrock UDP. Cambiare una porta non rende compatibili le due edizioni. Usa l’indirizzo assegnato nel pannello e verifica il destinatario di DNS o record SRV Java. Un accesso amministrativo raggiungibile non dimostra che la porta di gioco scelta sia quella corretta.
Il gameplay di Java utilizza generalmente un endpoint TCP, mentre il gameplay del server Bedrock utilizza UDP. Le impostazioni predefinite comuni non sostituiscono mai l'allocazione dei pannelli. Su un nodo condiviso, la copia di una porta predefinita da un tutorial può entrare in conflitto con un'altra istanza. Un test TCP non può convalidare la connettività Bedrock UDP.
Verificare solo il percorso TCP di Java da Windows
Test-NetConnection -ComputerName 192.0.2.10 -Port 25565Sostituisci indirizzo e porta con quelli assegnati al servizio. TcpTestSucceeded=True conferma solo la connessione TCP, non UDP Bedrock, autenticazione Minecraft o prestazioni. Con False confronta la porta in ascolto, l’avvio e le regole relative a quella specifica porta.
Verificare il completamento dell’avvio
Il processo può risultare attivo mentre il mondo viene caricato. Cerca il completamento dell’avvio e gli errori di Java, configurazione, plugin o mod. Se il servizio continua a riavviarsi, indaga prima questo ciclo. Riavvii ripetuti possono aumentare il carico e cancellare indizi; conserva i messaggi prima di modificare contemporaneamente più componenti.
Dopo aver aggiunto un plugin o un mod, controlla le sue dipendenze e la compatibilità del motore. Paper, Fabric, Forge e NeoForge non caricano automaticamente le stesse estensioni. Utilizzare una copia di prova e rimuovere solo l'aggiunta identificata; eliminare un mondo non è un modo per diagnosticare un errore del software.
Provare il protocollo corretto
Verifica l’abbinamento autorizzato fra IP pubblica e porta. Un test TCP non conferma la connettività Bedrock UDP. Con visibilità LAN attiva, Bedrock può aprire anche porte standard nonostante una porta personalizzata; su nodi condivisi deve rispettare lo schema del gestore. Non aprire porte aggiuntive o assegnate ad altre istanze per aggirare il problema.
Quindi confrontare da un'altra connessione autorizzata. Quando solo una rete fallisce, registra il suo provider e gli orari invece di modificare immediatamente la configurazione globale. Il ping ICMP bloccato non stabilisce che il gioco sia irraggiungibile; nemmeno una risposta ping dimostra che la porta del gioco è aperta.
Controllare il DNS Java senza modificare la zona
dig +short A play.example.com
dig +short SRV _minecraft._tcp.play.example.comUn record SRV Java può indicare una destinazione e una porta diverse. Risolvi anche il nome restituito e confrontalo con l’assegnazione. SRV non è necessario se il client usa già indirizzo e porta corretti. Questa non è una verifica UDP Bedrock.
Confrontare versioni e dipendenze
Controlla versione del gioco, software server e loader. Un modpack può richiedere la stessa combinazione sul client. Se il guasto segue una modifica, verifica quella dipendenza con una copia conservata. Un downgrade o un cambio di mondo può rendere incompatibili i dati. Non eliminare l’originale o tutte le cartelle delle estensioni per una prova senza diagnosi.
Il rilevamento LAN Bedrock può anche aprire le sue porte abituali oltre a una porta personalizzata. Su un nodo condiviso, utilizza la configurazione adattata del pannello e richiedi un controllo dei conflitti di allocazione. Per un proxy Java o un gateway crossplay, ispeziona ogni fase del percorso anziché solo l'indirizzo pubblico.
Misurare durante il problema
Osserva CPU, memoria e console nello stesso intervallo. Un thread principale saturo può bloccare il gioco anche con una media bassa sull’host. Su Paper, spark aiuta a profilare mentre il problema si presenta. Controlla distanze di visualizzazione e simulazione e possibili override in altre configurazioni: più RAM non risolve necessariamente quel lavoro.
Laddove supportato, profilare il server durante il problema con uno strumento compatibile. Le versioni recenti di Paper includono spark. Un report proveniente da un server vuoto è meno utile di uno acquisito durante il rallentamento. Associa la registrazione e proteggi i collegamenti diagnostici che potrebbero contenere informazioni sensibili.
Preparare informazioni riproducibili
Confronta un secondo accesso Internet e determina quali giocatori sono interessati. Salva ora, endpoint e messaggi pertinenti, togliendo credenziali e dati privati. Un timeout può dipendere da routing, filtri, protocollo errato o server non pronto. Attribuiscilo a un attacco o a risorse insufficienti soltanto quando misure di rete e applicazione sono coerenti.
L'attività sospetta di DDoS necessita di correlazione con misurazioni del traffico o eventi di mitigazione. Il timeout da solo non è una prova sufficiente. Evita riavvii ripetuti e scansioni aggressive: aggiungono carico e rendono più difficile la diagnosi. Testa la soluzione utilizzando una connessione normale, quindi controlla che i giocatori normali possano tornare.
Cosa fare nel tuo caso
| Situazione | Prossimo passo |
|---|---|
| Edizione sbagliata | Seleziona Java o Bedrock con il suo endpoint reale. Una porta diversa non converte l’edizione. |
| Guasto dopo mod o cambio mondo | Verifica versioni e dipendenze e conserva una copia separata dello stato precedente. |
| Problema soltanto sotto carico | Profila thread principale e chunk durante il guasto prima di scegliere un piano maggiore. |
Fonti ufficiali
Queste fonti descrivono i protocolli e le impostazioni citati. Controlla sempre la documentazione della tua versione.