不可避免的，我们在很多不同的场景下不得不和墙进行一系列接触，比如试图用更好的搜索引擎搜索，比如尝试获得一个词条更权威的解释，比如steam社区的各种操作，比如去pixiv上搜罗图片。如果不进行深究，其实有着各种简单的办法去绕过这个问题，但是很多时候，因为不同的理由穷，寻求另外的方法是必不可少的。

同样因为各种原因，下面会用不同的说法去代替一些常见的敏感词

DNS与DNS污染

DNS

DNS，Domain Name System，即域名系统，作为互联网服务，主要功能是将域名和IP地址相互映射的一个分布式数据库，能够使人更方便地访问互联网。DNS使用TCP和UDP端口53。这是日常上网中最为常用，也是必不可少的几个服务之一。
DNS主要使用UDP(用户数据报协议)传输查询结果，而这个协议没有其他验证手段，是不可靠的，(使用UDP的原因是效率高)。

DNS污染

DNS污染是墙之所以为墙最重要的方法之一。

DNS cache pollution，即网域服务器缓存污染，主要是用不同方法将域名指往不正确的IP地址。

1. 系统默认使用的ISP提供的域名查询服务器查询国外的权威服务器时即被污染，进而使其缓存受到污染，因此默认情况下查询ISP的服务器就会获得虚假IP地址。
2. 而用户直接查询境外域名查询服务器（比如 Google Public DNS）时有可能会直接被污染，从而在没有任何防范机制的情况下仍然不能获得目标网站正确的IP地址。
3. 对于真实的IP地址也可能会采取其它的手段进行封锁，或者对查询行为使用连接重置的方法进行拦截。

题外话-DNS劫持

虽然名字和上面的DNS污染很像，但是它和今天的主题没有太多联系。
通过某些手段取得某域名的解析记录控制权，进而修改此域名的解析结果，导致对该域名的访问由原IP地址转入到修改后的指定IP，使得对特定的网址不能访问或访问的是假网址。
DNS劫持最常见的症状是，使用某些运营商提供的宽带，打开部分页面都指向ISP提供的广告等页面。通常DNS劫持与运营商有关。

修正域名解析

hosts

hosts（域名解析文件）是一个用于储存计算机网络中各节点信息的计算机文件。这个文件负责将主机名称映射到相应的IP地址。hosts文件通常用于补充或取代网络中DNS的功能。和DNS不同的是，计算机的用户可以直接对hosts文件进行控制。
很多网址被DNS污染的方式进行了封锁而其真实ip没有被链接重置等其他方法封锁，在这种情况下在hosts中写入网址和已知的其网址的真实ip可以有效的避免DNS污染。
hosts的使用方法不做过多叙述，在网上可以随意搜到。
例：在不久之前pixiv可以使用修改hosts的方法直连，而steam社区也可以使用hosts进行直连避免链接不稳定

题外话-hosts的其他用法

可以将已知的广告服务器重定向到无广告的机器（通常是该计算机自身的IP地址：127.0.0.1）上来过滤广告。同时也可以通过不下载网络广告，从而减少带宽。
使用hosts文件还可以减少对DNS服务器的访问来加快访问速度并减少带宽消耗。

修改DNS

通常来说修改DNS仍会收到DNS污染，但是仍有一些特殊配置的小型DNS使用技术手段回避污染并提供不受污染的结果，通常使用这些小型DNS也能够访问其他被封锁的网站，例如中国科学技术大学DNS，清华大学DNS

SNI检测，CA证书检测和TCP连接重置

链接重置

服务器端在没有客户端请求的端口或者其他连接信息不符时，系统的TCP协议栈就会给客户端回复一个RESET通知消息，可见连接重置功能本来用于应对例如服务器意外重启等情况。而发送连接重置包比直接将数据包丢弃要好，因为如果是直接丢弃数据包的话客户端并不知道具体网络状况，基于TCP协议的重发和超时机制，客户端就会不停地等待和重发。
通过将TCP连接时服务器发回的SYN/ACK包中服务器向用户发送的序列号改为0，从而使客户端受骗认为服务器重置了连接而主动放弃向服务器发送请求。
监控特定IP地址的所有数据包，若发现匹配的黑名单动作（例如TLS加密连接的握手），其会直接在TCP连接握手的第二步即SYN-ACK之后伪装成对方向连接两端的计算机发送RST数据包（RESET）重置连接，使用户无法正常连接至服务器。

SNI

SNI，即服务器名称指示，它是一个扩展的TLS计算机联网协议，在该协议下，在握手过程开始时客户端告诉它正在连接的服务器要连接的主机名称。这允许服务器在相同的IP地址和TCP端口号上呈现多个证书，并且因此允许在相同的IP地址上提供多个安全（HTTPS）网站而不需要所有这些站点使用相同的证书。所需的主机名未加密，因此窃听者可以查看请求的网站。
在过去通常一个ip提供单个服务，因此一个证书便可以解决问题。而新技术的出现和各种需求的变化（例如虚拟主机技术），负责多个主机名的服务器可能需要为每个名称（或一组名称）提供不同的证书，这时就需要SNI进行协调。
SNI通过让客户端发送虚拟域名的名称作为TLS协商的一部分来解决此问题。这使服务器能够提前选择正确的虚拟域名，并向浏览器提供包含正确名称的证书。因此，对于实现SNI的客户端和服务器，具有单个IP地址的服务器可以在获取公共证书不现实的情况下提供一组域名。

SNI 检测

由于SNI信息并非加密的，允许审查者区分出“真实”和“虚假”的服务或者识别出用户访问的网站域名。使用SNI检测技术可以使监听者查看请求的网站，并使用其他技术进行干扰。

总结

当上述手段结合使用，以往的hosts法或其他修正域名解析的方法将成为历史。
实际上steam社区和pixiv在18年底已经均无法继续通过修改hosts访问。

代理与本地反代理

代理

代理就是...
咳咳咳
请去阅读学习计网，或者自行百度

反代理

即反向代理，单纯的反向代理其实和本篇主题关系不是很大，CDN就是反向代理的一个应用。

CDN

CDN的基本原理是广泛采用各种缓存服务器，将这些缓存服务器分布到用户访问相对集中的地区或网络中，在用户访问网站时，利用全局负载技术将用户的访问指向距离最近的工作正常的缓存服务器上，由缓存服务器直接响应用户请求。
来自百度百科

避免SNI过滤，自签名与本地反代理

如何避免SNI过滤呢？
思路是防止SNI暴露
网站会使用CDN进行响应用户请求，可以将被封锁域名修改为同CDN的ip
但是直接本地修改SNI头会导致SSL证书问题（ERR_SSL_DECRYPT_ERROR_ALERT）
使用本地反代理（Nginx）时可以防止向外SNI，再使用自签名的CA证书可以解决问题

实例

steam社区访问：steamcommunity 302
pixiv：さくら荘の白猫

尾声

写到底发现大部分内容都在前期的基础扫盲，而后面关于代理等其他方法，一方面是代理本身的敏感性不敢在博客中正大光明的写出（以前写过一个ss使用教程博客被查水表。。），另一方面是本地反代理之前没有接触过，也不是十分常用，所以无法十分详细透彻的写出。
写这篇文章是我最近为了正常使用steam社区和pixiv发现大佬们均采用了这种方法，而在使用过程中产生了一些问题。
steam玩家熟知的steamcommunity 302这个软件就是用这个办法解决问题的。
而如果研究pixiv的同学应该也可能在さくら荘の白猫这个博客中找到了解决办法。
因为两个我都会使用，最终导致出现了新的问题，在开启steamcommunity 302这个软件的同时访问p站会出现错误，具体表现是登录p站时浏览器会提示证书只适用于steamcommunity，对比了两篇文章的时间猜测应该是白猫庄的作者参考了steamcommunity 302的解决方案导致冲突，或者是steamcommunity 302 V8本地反代模式会随机生成Steam社区证书用于实现本地反代，导致pixiv的证书出现问题。
因为懒，所以现在就只能在想上b站的时候关闭steamcommunity 302 V8好在平时也不经常使用

Encore！

所以还是找一个好的代理再充满流量最方便辣！