编辑
我设法找出了我所缺少的东西，这清楚地表明了如何解决我的问题。事实证明，在 16.04 和 18.04 之间，Ubuntu 和衍生产品从基于 dnsmasq 的东西默认切换到基于 systemd-resolved 的东西，并且 systemd-resolved 比 dnsmasq 更不愿意承受/etc/hosts.
下面是我试图描述的原始问题，我只是在编辑页面上添加这个关于这里有答案的问题，因为我认为我应该修复标签以更好地反映结果相关组件。
原帖
所以，我最近从 xenial (16.04) 转移到了仿生 (18.04)，并且我在解决至少我认为有解决方案的问题方面取得了很大的成功。我想我要归结为最后一件事，这不是我希望的那样，我希望有一个解决办法。
在 16.04 中，我曾经有一个很长的主机文件，甚至无法加载已知的恶意站点。它对我来说效果很好，如果有任何问题，我可以检查相关域是否存在，检查它是如何到达那里的，并自行决定是否将其取消列入黑名单。
我试图从带有 16.04 的旧驱动器中迁移我的主机文件，但突然之间什么都加载不出来，所以我不得不恢复。在比较了一下之后，我发现了一个微小的差异（我的新主机文件包括我的计算机主机名的两个版本，一个以“.lan”结尾）并尝试纠正它以查看它是否可以解决问题。没有骰子。
我可以将项目添加到列表中，如果我复制我的域候选列表，我只是不想加载那些被阻止的好，但是当我添加曾经工作的大量列表时，它似乎使 DNS 永远占用并且永远不会解决任何问题. 这是我几天前以同样方式添加的主机列表。
我最好的想法是从哪里开始尝试进一步研究 xenial 和 bionic 之间的网络发生的任何变化（我不得不重新控制我的现代 eth0 名称，因为一些新的东西试图自动-管理它），但我什至花了一些时间才找到成功让我重新控制有线网络的指南，老实说，我什至不确定更改的整个范围是什么。
有没有其他人使用主机文件来阻止一堆域并碰巧知道这里发生了什么？是否有一些设置更改了默认设置并影响主机文件解析，我需要将其设置为旧设置或其他什么？我会对文件本身更加怀疑，但它在 xenial 下工作得很好，这让我相当确定仿生的变化是相关的，而不仅仅是主机文件本身是错误的（或者如果是，它是错误的一种在历史上一直有效的方式，我一直在使用相同的来源）。