Wi-Fi spune conectat, nimic nu se încarcă: resolverele Mac vechi

Trimiteți un ping către o adresă literală și răspunde. Deschideți un site după nume și nu se întâmplă nimic, în timp ce pictograma de rețea insistă că legătura e în regulă. Pe un Mac care tocmai s-a alăturat unui VPN, combinația aceea înseamnă aproape întotdeauna că interogările sunt îndreptate spre un server care nu mai e accesibil, nu că rețeaua a căzut. Adresele au fost fixate cândva pe serviciul Wi-Fi și nimic nu le-a eliminat de atunci. Diagnosticați prin eliminare, apoi ștergeți intrările fixate.

Reparația este o ștergere, nu o golire, iar diferența contează pentru că comenzile pe care majoritatea le încearcă mai întâi fac cu totul altceva.

Conectat este o afirmație despre legătură

macOS ține o configurație de resolver pentru fiecare serviciu de rețea. Valorile de la DHCP sunt o sursă, cele tastate manual alta, iar cele împinse de un profil sau scrise de un client sunt a treia. Cele fixate au prioritate față de ce oferă rețeaua, și nimic din stivă nu le revalidează. De aceea un server care a dispărut rămâne în listă până când o persoană îl elimină sau serviciul este reconstruit de la zero.

De aceea un tunel care își încheie strângerea de mână nu schimbă nimic într-o interogare care era deja direcționată greșit. VPN-ul a adăugat un resolver; nu l-a auditat pe cel care eșua.

Separați numele de pachete

Mai întâi ajungeți la un host prin adresa literală. Când se încarcă, pachetele sunt în regulă și resolverul e vinovat. Când nu se încarcă, opriți-vă acolo și tratați problema ca pe una de rutare, pentru că modificările DNS vor adăuga doar o variabilă la o imagine deja confuză.

Un nume care eșuează în timp ce adresa corespunzătoare funcționează este amprenta. Observați și domeniul de aplicare: dacă totul eșuează, indică o intrare globală stricată, iar dacă eșuează doar gazdele din interiorul tunelului, indică un alt proprietar și o reparație mai îngustă.

Ștergeți serverele fixate

În Configurări de rețea, deschideți detaliile serviciului Wi-Fi și treceți la fila DNS. Eliminați fiecare rând de server, confirmați schimbarea, apoi parcurgeți domeniile de căutare pentru valori pe care nu le-ați adăugat niciodată. Lăsați lista goală, reconectați serviciul și confirmați că adresa furnizată de DHCP reapare singură. O listă goală este starea temporară care dovedește că valorile fixate erau problema.

Versiunile mai vechi ascund același panou un nivel mai adânc, în spatele unui buton Avansat, cu comportament identic și același rezultat.

Citiți starea, nu panoul

scutil --dns | head -40 afișează resolverele pe care macOS le folosește efectiv, grupate după domeniu, iar un nslookup rapid al unui nume intern cunoscut arată dacă sosește vreun răspuns. Comparați cele două ieșiri: un panou curat cu un server vechi încă listat înseamnă că alt scriitor deține setarea aceea. Acela este un alt bug, cu altă reparație.

Când ambele arată curat și numele încă eșuează, defectul s-a mutat în altă parte și nu mai depanați configurația DNS.

Cine pune intrările la loc

Serverele care revin după ștergere au o sursă. Verificați Gestionarea dispozitivelor pentru un profil de configurare, pentru că profilurile pot purta DNS și sunt reevaluate după propriul calendar. Verificați preferințele clientului pentru o opțiune de setare a DNS la conectare și decideți dacă mai merită locul pe acest calculator. Dacă VPN-ul are cu adevărat nevoie de un resolver privat, limitați-l la domeniile pe care le deține, în loc să scrieți în lista globală pe care o moștenește fiecare rețea viitoare.

Notați resolverul dorit și domeniile la care trebuie să răspundă. După următoarea actualizare a clientului, verificați un nume public și unul privat, ceea ce este mai rapid decât repetarea plimbării prin setări și prinde regresia cât timp calculatorul este încă în mâinile voastre.

Orice altceva este teatru de întreținere: comenzi care par deliberate, nu schimbă nimic măsurabil și lasă aceeași interogare stricată pentru următoarea persoană.