可見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文件可以恢復正常。
