Wi-Fi säger ansluten, ingenting laddas: inaktuella resolvers på Mac

Pinga en bokstavlig adress och den svarar. Öppna en webbplats på namn och ingenting händer, medan nätverksikonen hävdar att anslutningen är i ordning. På en Mac som just anslutit till en VPN betyder den kombinationen nästan alltid att uppslagningen riktas mot en server som inte längre går att nå, inte att nätverket ligger nere. Adresserna fästes vid Wi-Fi-tjänsten någon gång tidigare och ingenting har tagit bort dem sedan dess. Diagnostisera genom uteslutning och ta sedan bort de fästa posterna.

Reparationen är en borttagning och inte en tömning, och skillnaden spelar roll eftersom kommandona som de flesta provar först gör något helt annat.

Ansluten är ett påstående om länken

macOS håller en resolverkonfiguration per nätverkstjänst. Värden från DHCP är en källa, inskrivna värden en annan och värden som en profil trycker ut eller en klient skriver en tredje. De fästa går före det nätverket erbjuder, och ingenting i stacken validerar dem på nytt. En server som är borta blir därför kvar i listan tills en människa tar bort den eller tjänsten byggs upp från grunden.

Därför ändrar en tunnel som slutför sitt handskakning ingenting i en uppslagning som redan var felriktad. VPN:en lade till en resolver; den granskade inte den som misslyckades.

Skilj namn från paket

Nå först en värd via den bokstavliga adressen. När det laddas är paketen i ordning och resolver är boven. När det inte laddas, stanna där och behandla problemet som ett routingproblem, eftersom DNS-ändringar bara lägger till en variabel i en redan förvirrande bild.

Ett namn som misslyckas medan den matchande adressen lyckas är fingeravtrycket. Notera omfattningen också: när allt misslyckas pekar det på en trasig global post, medan när bara värdar inne i tunneln misslyckas pekar det på en annan ägare och en snävare reparation.

Ta bort de fästa servrarna

I Nätverksinställningar, öppna detaljerna för Wi-Fi-tjänsten och byt till DNS-fliken. Ta bort varje serverrad, bekräfta ändringen och gå sedan igenom sökdomänerna efter värden du aldrig har lagt till. Låt listan stå tom, anslut tjänsten igen och bekräfta att adressen som DHCP levererar dyker upp av sig själv igen. En tom lista är det tillfälliga tillstånd som bevisar att de fästa värdena var problemet.

Äldre utgåvor gömmer samma panel en nivå djupare, bakom en Avancerat-knapp, med identiskt beteende och samma resultat.

Läs tillståndet, inte panelen

scutil --dns | head -40 skriver ut de resolvers macOS faktiskt använder, grupperade efter omfattning, och en snabb nslookup av ett känt internt namn visar om det överhuvudtaget kommer ett svar. Jämför de två utdata: en ren panel med en inaktuell server fortfarande listad betyder att en annan skribent äger den inställningen. Det är en annan bugg med en annan lösning.

När båda ser rena ut och namn fortfarande misslyckas har felet flyttat någon annanstans och du felsöker inte längre DNS-konfigurationen.

Vem som sätter tillbaka posterna

Servrar som kommer tillbaka efter borttagning har en källa. Kontrollera Enhetshantering efter en konfigurationsprofil, eftersom profiler kan bära DNS och omvärderas enligt sitt eget schema. Kontrollera klientens inställningar efter ett alternativ att sätta DNS vid anslutning och avgör om det fortfarande förtjänar sin plats på den här maskinen. Om VPN:en verkligen behöver en privat resolver, begränsa den till de domäner den äger i stället för att skriva i den globala listan som varje framtida nätverk ärver.

Anteckna den avsedda resolvern och de domäner den ska svara på. Efter nästa klientuppdatering, verifiera ett offentligt och ett privat namn, vilket är snabbare än att upprepa inställningsrundan och fångar regressionen medan maskinen fortfarande är i dina händer.

Allt annat är underhållsteater: kommandon som ser avsiktliga ut, inte ändrar något mätbart och lämnar samma trasiga uppslagning till nästa person.