不知大家是否遇到過Hosts文件失效的問題。原本我的Windows 8.1系統的Hosts文件可以正常使用,但是最近不知何故突然失效了。Hosts文件失效給我工作帶來很多麻煩,為了分析具體原因,我給大家做個演示測試。
可見hosts文件路徑是對的,而且只有一行映射,確保沒有其他的干擾項。
使用ipconfig /flushdns清理DNS緩存,而且其實我還停止了DNS Client服務的。然後繼續ping,依然返回的是真實DNS解析的地址。
可見system的權限也是有分配的。下面那個我自己的賬戶和Admin組的賬戶的權限也是完全控制的。
情況就是這樣,不知為何最近突然失效了。我可能是遇到什麼劫持了麼?
分析處理
根據引用中我的猜想,我使用了消息記錄器來跟蹤與hosts文件有關的系統消息。為了對比,我同時在windows 8.1和虛擬機中運行的windows XP下操作,以便作為對比。
首先我發現其實所有有網絡通信功能的程序都會去檢測HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesDnscacheParameters這個鍵下面是否存在UseHostsFile值是否存在,數據是多少。但是我發現無論XP還是8.1都沒有該值,但是根據之前的實驗可知是XP可以正常讀取hosts文件的,所以可以斷定這個是無關項。(不過根據這個判斷,原來Dnscache服務(也就是在服務中顯示名稱為DNS Client的服務,用於緩存DNS解析的結果)是可以手動強制不讀取hosts文件的,修改這個鍵值即可)
然後我發現一個怪異的現象,每次我手動修改hosts文件後,在8.1下會顯示出一個名為svchost.exe的進程試圖訪問hosts文件但是結果為Acces Denied。在XP下,也有同樣名稱的進程試圖訪問hosts文件但是結果卻是Success的。
根據消息記錄器提供的進程的PID,追蹤到其承載的服務中有一個共同的服務就是DNS Client。於是可以斷定肯定是上述提到的DNS Client服務出現問題了。因為出現訪問文件被拒,肯定是帳戶問題,於是我習慣性地打開DNS Client的屬性頁,轉到登錄選項卡,發現其使用的帳戶不是默認本地系統帳戶,而是名為“Network Service”的內置安全主體。
到此一切都明了了,歸根到底還是權限問題。DNS Client服務使用的帳戶不是system,而是Network Service。雖然我給system帳戶賦予了完全的訪問控制,但是根據我開篇的截圖可以發現,我裡面缺少了Network Service的安全主體。而現在我們可以斷定system帳戶和Network Service安全主體是沒有關聯的,所以才導致了DNS Client服務啟動後無法正常讀取hosts文件,而導致hosts文件無效。
解決辦法就是:編輯etc文件夾的訪問權限,添加Network Service安全主體並賦予至少允許讀取的權限,然後重新啟動DNS Client服務即可。目前我的hosts已經一切正常。
通過以上的分析,相信大家能夠更清楚地理解Windows 8.1系統下Hosts文件失效的原因,也能夠掌握解決它的應對措施。最終,我們的Hosts文件可以恢復正常。