2019.6救活被ban的IP

连开一二十台服务器全都被ban了ip, 找到一个用websocket+tls+nginx+cdn救活ip的办法, 尝试一下.

垃圾vultr取消了3.5$的服务器, 现在只能用5$的了

原理:

通过位于国外的cdn节点转发fq流量, 共经过两次代理穿Q而出.

步骤:

先开服装bt装nginx装v2接入cdn等等

对了,你需要有另一个渠道番Q, 才能ssh连上你被墙的服务器

服务端v2配置:

{
  "log": {
  "access": "/v2la",
  "error": "/v2le",
  "loglevel": "debug"
  },
  "inbounds": [
    {
      "port": 3456,
      "listen":"127.0.0.1",
      "protocol": "vmess",
      "settings": {
        "clients": [
          {
            "id": "#",
            "alterId": 4
          }
        ]
      },
      "streamSettings": {
        "network": "ws",
        "wsSettings": {
        "path": "/abc"
        }
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "freedom",
      "settings": {}
    }
  ]
}

nginx中添加一条反代规则, 把example.com/abc:443的流量解密并转发至v2监听的端口3456, 与此同时访问example.com:443的流量还是转发到一个正常的网站上, 达到伪装效果.

location /abc
    {                            
        proxy_redirect off;
        proxy_pass http://127.0.0.1:3456;      
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $http_host;
    }

关于SSL的解密设置, 无需手动写入反代规则中. 直接利用bt面板的SSL配置功能即可.

服务端安装cloudflare自签的证书, 然后再把cdn的加密模式调成full, 即可实现从客户端到目标的全程tls加密.

注意记得启用cdn代理(云朵点亮).

cloudflare有个坑的地方就是加密设置是全局的, 我同一个域名下的另一个站不支持https, 只能禁用其cdn代理.

以下是客户端关键配置: (有了TLS之后vmess本身的加密就可以关掉了)

"outbound": {
        "protocol": "vmess",
        "settings": {
            "vnext": [
                {
                    "address": "example.com",
                    "port": 443,
                    "users": [
                        {
                            "id": "#",
                            "alterId": 4,
                            "security": "none"
                        }
                    ]
                }
            ]
        },
     "streamSettings": {
         "network":"ws",
         "security":"tls",
         "tlsSettings":{
             "serverName":"example.com",
             "allowInsecure": false
         },
         "wsSettings":{
             "path":"/abc"
         }
     },
        "mux": {
            "enabled": true
        }
    }

结果

我们惊喜的发现又可以番Q了.

不过还是存在严重的问题:

    • 由于多次转发和多次tls加密, 延迟高达1s+
    • 由于不明原因, 断流严重, 出现过下列错误现象: 时常完全无法连接, 但一旦连接得上速度会很快. 第一次打开一个网页连不上或只加载出一部分, 刷新一次又能正常打开. 上述现象每隔一段不固定的时间就会出现.
      浏览器:
      ERR_SSL_VERSION_INTERFERENCE
      ERR_EMPTY_RESPONSE
      ERR_Connection_Closed
      ERR_CONNECTION_TIMED_OUT

      服务端客户端错误信息无意义, 已省略.

结论

  • 可疑ip大把封禁, 关机保平安.
  • ws+tls+nginx这一套效果不错, 可以作为长期解决方案.
  • 断流也可能是被Qos

以上皆为6.12的尝试, 但配置修改为了最终版本

Update(6.13)

断流问题是正常现象, 因为走CDN要绕很多路. 而且也有随机的干扰.(在github上开issue得到的解答)

所以不得已要用cdn时还是要选离cdn节点近的vps.

晚上开到一台没被ban的VPS, 立马尝试ws+tls+nginx, 效果极佳, 断流现象大幅减少.

另外, 已经经过了tls加密, 客户端配置加密写为none也是可以的, 速度略微提升.

使用websock+TLS+nginx/caddy伪装的好处:

  • 从外面看完全属于通过443端口访问正常的HTTPS网站
  • websocket的path(比如/abc)被TLS加密不能被探测到
  • TLS不是伪装,不是混淆,是真正的HTTPS,用途合理永远不能被封锁

Update(7.22)

找到一个钦定Cloudflare最近节点的方法, 详见Cloudflare节点利用技巧

钦定之后速度大幅提升, 无断流现象.

PS: vultr服务器以45开头的IP都访问不了某网站, 这是某网站的主动屏蔽, 与Q无关. 于是整体搬迁到一个新加坡的服务器, 搬之后忘了开443端口(3456不用对外网开放), 折腾好久.

赞(0)

评论 1

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址
  1. #1

    ORZ

    winlere 4个月前 (07-27) 这家伙可能用了美佬的代理 谷歌浏览器 Ubuntu Linux 回复