Innan du börjar
Ta fram speladress och port, felens tidpunkt, panelstatus och relevant konsol. Anteckna senaste resursändringar. Ta bort nycklar och lösenord från delade loggar och behåll fungerande filer för att kunna återgå till tidigare läge.
Bekräfta att spelet är redo
En körande process tar inte alltid emot spelare ännu. Leta efter fel i inställningar, resurser eller ofärdig txAdmin-installation. Använd spelporten från panelen: administrationsporten för txAdmin ersätter den inte. På en delad nod får du inte anta standardporten eller en annan kunds port. Bekräfta tilldelning och färdig uppstart före nätverkstester. Spara förklarande meddelanden i stället för upprepade omstarter utan diagnos.
Spela in det visade scenen och felen i F8-konsolen. Misslyckande att ansluta, en avstannad nedladdning och en laddningsskärm efter nedladdningar pekar på olika komponenter. Ändra en sak i taget och registrera vad varje test visar.
Jämför direktåtkomst och listan
Prova tilldelad adress från klientens F8-konsol och sedan åtkomst via listan. Om bara en väg fungerar, anteckna skillnaden. Ändra inte annonsering, IP och portar slumpmässigt; kontrollera dokumenterade ändpunkter och operatörens upplägg. En annan instans på samma värd är inte reservadress för din tjänst. Hitta steget med olika resultat så att problemet kan upprepas och undersökas utan att påverka andra kunder.
Kontrollera att FXServer har startat, dess slutpunkter matchar allokeringen och nätverksreglerna täcker de nödvändiga protokollen. Ett framgångsrikt TCP-test visar inte att UDP fungerar. För hanterad värd, använd panelinställningarna och begär en tilldelningskontroll innan du ändrar värdbrandväggens regler.
Skilj HTTP från speltrafik
Filer och HTTP-ändpunkter kan svara medan UDP inte fungerar. Testa nedladdning, inträde och administration var för sig. Ett svar från info.json bevisar inte hela UDP-vägen. Ett TCP-test bekräftar inte heller alla anslutningar genom proxy och filter. Kontrollera den faktiska spelarens anslutning och nedladdning, inte bara en sida. Anteckna fungerande delar och blanda inte olika protokoll till en felaktig slutsats om hela tjänsten.
Återskapa problemet på en testkopia med en minimal resursuppsättning, lägg sedan till tillägg gradvis. Inaktivera inte slumpmässigt skript på en live-gemenskapsserver. Kontrollera filstorlekar och ledigt utrymme: att flytta en stor resurs till en cache reparerar inte dess skript- eller beroendefel.
Undersök senaste resursändringen
Om problemet följde en uppdatering, behåll läget och kontrollera ändringen med beroenden och startordning. Utgå från konkreta meddelanden och ändra en sak under aviserat underhåll. Radering av resurser eller klientcache tar bort spår och reparerar inte en felaktig ändpunkt eller vidarebefordran. Spara filer, testbeskrivning och resultat före nästa ändring. Återgång till äldre version måste även ta hänsyn till data och beroenden.
Jämför annonserade adresser, anslutningsändpunkter och fildestinationer med dokumentationen för din version. En exponerad ursprungsadress kan kringgå fjärrskydd. Bekräfta routing och täckt trafik innan du begränsar ursprunget: blockering av en legitim tjänst, rösttrafik eller en nödvändig port kan förvärra avbrottet.
Kontrollera proxy och ursprungsserver
Offentliga ändpunkter, tillåtna källor och regler ska matcha den verkliga topologin. Cfx.re dokumenterar rollerna separat. Lita inte på hela internet som proxy och ta inte bort skydd för enkelhetens skull. Avtala jämförelse utan mellanled som ett begränsat kontrollerat test med operatören och klar återgång. Kopiera inte en annan versions inställningar utan stöd. Kontrollera behörigheter och trafik till ursprung och tillbaka före åtkomstbegränsning.
Innan du ändrar artefakter, kontrollera ramverk och resursförutsättningar, säkerhetskopiera och testa den valda versionen. FiveM för GTA V Enhanced introducerar ändringar som kan komma i konflikt med Legacy-konfigurationer. En nyare artefakt som är tillgänglig certifierar inte automatiskt din installation, skript eller värdmall som kompatibla.
Förbered en upprepningsbar felbeskrivning
Jämför oberoende åtkomster när det går och identifiera berörda spelare. Behåll tid, adress och användbara loggar utan hemligheter. Timeout bevisar inte DDoS: jämför trafik, filter och belastning. En konkret procedur skiljer lokalt problem, program och väg och minskar slumpmässiga ingrepp hos andra kunder. Ge supporten scenario och tid med lyckade och misslyckade steg, inte bara en känsla av att servern ibland fastnar.
Om du misstänker en attack, begär korrelation med begränsningshändelser eller nätverksmätningar. Enbart en timeout visar inte en DDoS-attack. Undvik upprepade omstarter, improviserade belastningstester och globalt inaktiverande säkerhet: dessa kan skymma orsaken eller skapa ett nytt avbrott.
Vad gör du i din situation?
| Situation | Nästa steg |
|---|---|
| Uppstarten är inte klar | Kontrollera inställningar och konsol och bekräfta redo-läge före nätverksslutsatser. |
| Filer fungerar, inträdet misslyckas | Bekräfta adress och UDP-vidarebefordran. HTTP-framgång testar inte hela vägen. |
| Fel efter en resurs | Gör en kopia och testa ändringen med beroenden under underhåll. |
Officiella källor
Källorna beskriver protokoll och inställningar. Kontrollera dokumentationen för versionen du använder.