查看/etc/modprobe.d/disable_ipv6.conf

[root@ali_abc ~]# cat /etc/modprobe.d/disable_ipv6.conf 
alias net-pf-10 off
options ipv6 disable=1

修改为下面的值

[root@ali_abc ~]# vim /etc/modprobe.d/disable_ipv6.conf 
alias net-pf-10 off
options ipv6 disable=0

查看/etc/sysconfig/network

[root@ali_abc ~]# cat /etc/sysconfig/network
# Created by anaconda
NETWORKING_IPV6=no
  ERNTP=no

修改为下面的值

[root@ali_abc ~]# vim /etc/sysconfig/network
# Created by anaconda
NETWORKING_IPV6=yes
  ERNTP=no

查看/etc/sysctl.conf

[root@ali_abc ~]# cat /etc/sysctl.conf 
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

修改为下面的值

[root@ali_abc ~]# vim /etc/sysctl.conf 
net.ipv6.conf.all.disable_ipv6 = 0
net.ipv6.conf.default.disable_ipv6 = 0
net.ipv6.conf.lo.disable_ipv6 = 0

重启

[root@ali_abc ~]# sysctl -p

he.net IPv6隧道

HE.net IPv6 Tunnel Broker – CentOS/RHEL/Fedora NIC config

ifcfg-he-ipv6

DEVICE="he-ipv6"
DEVICETYPE=sit
BOOTPROTO=none
ONBOOT=yes
IPV6INIT=yes
IPV6TUNNELIPV4=184.105.253.10
IPV6TUNNELIPV4LOCAL=XXX.XXX.XXX.XXX
IPV6ADDR=2001:470:YYYY:YYYY::2/64
IPV6_DEFAULTGW=2001:470:YYYY:YYYY::1
IPV6ADDR_SECONDARIES=2001:470:YYYY:YYYY::3/64
ZONE=public

route6-he-ipv6

::/0 dev he-ipv6

查看IPv6路由

[arben@ali_arben ~]$ route -6 -n
::/0            2001:470:1f04:295::1       UG   1   1   948 he-ipv6
可以看到ipv6默认路由的下一跳地址是隧道另一端的地址

测试

[root@ali_abc ~]# ping6 google.com
PING google.com(hkg12s13-in-x0e.1e100.net (2404:6800:4005:808::200e)) 56 data bytes
64 bytes from hkg12s13-in-x0e.1e100.net (2404:6800:4005:808::200e): icmp_seq=1 ttl=54 time=332 ms
64 bytes from hkg12s13-in-x0e.1e100.net (2404:6800:4005:808::200e): icmp_seq=2 ttl=54 time=332 ms

使用ping6命令，而不是ping命令。

最近 Surge 又更新了，支持 Javascript 了，更强大了。

意味着 Surge 可以通过脚本执行更多的操作，更像是一个网络调试软件，而非翻墙工具了。

可以借助 Javascript 不仅仅只是去广告，但是去广告的效果会更好。

例如：

去微博应用内广告

代码来源：yichahucha/surge

[Script]

# 去微博应用内广告
http-response ^https?:\/\/api\.weibo\.cn\/2(\/groups\/timeline|\/statuses\/unread|\/statuses\/extend|\/comments\/build_comments|\/photo\/recommend_list|\/stories\/video_stream|\/statuses\/positives\/get|\/stories\/home_list|\/profile\/statuses|\/statuses\/friends\/timeline) script-path=https://raw.githubusercontent.com/yichahucha/surge/master/wb_ad.js

# 微博启动页广告
http-response ^https?:\/\/(sdk|wb)app\.uve\.weibo\.com(\/interface\/sdk\/sdkad.php|\/wbapplua\/wbpullad.lua) script-path=https://raw.githubusercontent.com/yichahucha/surge/master/wb_launch.js

主机名添加：api.weibo.cn、*.uve.weibo.com

[MITM]

hostname = api.weibo.cn, *.uve.weibo.com

借助Surge防剧透

代码来源：Blankwonder

[Script]

# 防剧透
http-response .* script-path=https://gist.githubusercontent.com/Blankwonder/72fcdd46d1d9148f5461c6b59d859551/raw/12fd2c6b1be806596766f5fab825d1bd5f770cb2/anti-spoiler.js

主机名

[MITM]

# 全局生效
hostname = *

酷我音乐

代码来源：Choler/Surge

[Script]

# 酷我音乐
http-response ^http://vip1\.kuwo\.cn/vip/ script-path=https://raw.githubusercontent.com/ydzydzydz/Rules/master/resources/js/Music.js

去微信广告

代码来源：Choler/Surge

[Script]

# 去微信广告
http-response ^https?://mp\.weixin\.qq\.com/ script-path=https://raw.githubusercontent.com/ydzydzydz/Rules/master/resources/js/WeChat.js

主机名添加：mp.weixin.qq.com

[MITM]

hostname = mp.weixin.qq.com

微信阅读小程序

代码来源：Choler/Surge

[Script]

# 微信阅读小程序
http-response ^https?://i\.weread\.qq\.com/pay/memberCard script-path=https://raw.githubusercontent.com/ydzydzydz/Rules/master/resources/js/WeRead.js 

主机名添加：i.weiread.qq.com

[MITM]

hostname = i.weiread.qq.com

RRtv

代码来源：Choler/Surge

[Script]

# RRtv
http-response ^https?://api\.rr\.tv/ script-path=https://raw.githubusercontent.com/ydzydzydz/Rules/master/resources/js/RRtv.js

主机名添加：api.rr.tv

[MITM]

hostname = api.rr.tv

知音漫客

代码来源：mieqq/mieqq

[Script]

# 知音漫客
http-response getuserinfo-globalapi.zymk.cn script-path=https://raw.githubusercontent.com/mieqq/mieqq/master/zymk.js

主机名添加：*.zymk.cn

[MITM]

hostname = *.zymk.cn

知乎去广告

代码来源：onewayticket255/Surge-Script

[Script]

# 知乎去广告
http-response https://api.zhihu.com/(topstory/follow|moments) script-path=https://raw.githubusercontent.com/onewayticket255/Surge-Script/master/surge%20zhihu%20feed.js
http-response https://api.zhihu.com/topstory/recommend script-path=https://raw.githubusercontent.com/onewayticket255/Surge-Script/master/surge%20zhihu%20recommend.js
http-response https://api.zhihu.com/v4/questions script-path=https://raw.githubusercontent.com/onewayticket255/Surge-Script/master/surge%20zhihu%20answer.js
http-response https://api.zhihu.com/market/header script-path=https://raw.githubusercontent.com/onewayticket255/Surge-Script/master/surge%20zhihu%20market.js

主机名添加：api.zhihu.com

[MITM]

hostname = api.zhihu.com

bilibili概念版去广告

代码来源：onewayticket255/Surge-Script

[Script]

# bilibili概念版去广告
http-response https://app.bilibili.com/x/resource/show/tab script-path=https://raw.githubusercontent.com/onewayticket255/Surge-Script/master/surge%20bilibili%20tab.js
http-response https://app.bilibili.com/x/channel/list script-path=https://raw.githubusercontent.com/onewayticket255/Surge-Script/master/surge%20bilibili%20channel.js
http-response https://app.bilibili.com/x/v2/feed script-path=https://raw.githubusercontent.com/onewayticket255/Surge-Script/master/surge%20bilibili%20feed.js
http-response https://app.bilibili.com/x/v2/account/mine script-path=https://raw.githubusercontent.com/onewayticket255/Surge-Script/master/surge%20bilibili%20account.js
http-response https://app.bilibili.com/x/v2/view.access_key script-path=https://raw.githubusercontent.com/onewayticket255/Surge-Script/master/surge%20bilibili%20view%20relate.js

主机名添加：api.bilibili.com

[MITM]

hostname = app.bilibili.com

简体转换为繁体

代码来源：mieqq/mieqq

[Script]

# 简体转换为繁体
http-response .* script-path=https://raw.githubusercontent.com/mieqq/mieqq/master/SimplifiedToTraditional.js

主机名

[MITM]

# 全局转换
hostname = *

Meeta (石头阅读）

代码来源：MeetaGit/MeetaRules

[Script]

# Meeta (石头阅读）
http-response https?:\/\/app\.stoneread\.com/api\/apiClient\/index\?data script-path=https://raw.githubusercontent.com/MeetaGit/MeetaRules/master/Surge/Scripting/StoneRead.js

主机名添加：app.stoneread.com

[MITM]

hostname = app.stoneread.com

Meeta （网易漫画）

代码来源：MeetaGit/MeetaRules

[Script]

# Meeta（网易漫画）
http-response https?:\/\/api\.mh\.163.com\/getUserProfile script-path=https://raw.githubusercontent.com/MeetaGit/MeetaRules/master/Surge/Scripting/wymh.js

主机名添加：api.mh.163.com

[MITM]

hostname = api.mh.163.com

Meeta（爱美剧下载）

代码来源：MeetaGit/MeetaRules

[Script]

# Meeta（爱美剧下载）
http-response https?:\/\/mjappaz.yefu365.com\/index.php\/app\/ios\/ script-path=https://raw.githubusercontent.com/MeetaGit/MeetaRules/master/Surge/Scripting/aimeiju.js

主机名添加：mjappaz.yefu365.com

[MITM]

hostname = mjappaz.yefu365.com

Meeta（微信读书）

代码来源：MeetaGit/MeetaRules

[Script]

# Meeta（微信读书）
http-response https?:\/\/i\.weread\.qq.com\/pay\/memberCardSummary\?pf script-path=https://raw.githubusercontent.com/MeetaGit/MeetaRules/master/Surge/Scripting/wechatread.js

主机名添加：i.weread.qq.com

[MITM]

hostname = i.weread.qq.com

Meeta（西瓜视频）

代码来源：MeetaGit/MeetaRules

[Script]

# Meeta（西瓜视频）
http-response https?://api.gkaorlz.com/api/user/get script-path=https://raw.githubusercontent.com/MeetaGit/MeetaRules/master/Surge/Scripting/watermelonvideo.js

主机名添加：api.gkaorlz.com

[MITM]

hostname = api.gkaorlz.com

Meeta（哔哩哔哩）

代码来源：MeetaGit/MeetaRules

[Script]

# Meeta（哔哩哔哩）
http-response https?://app.bilibili.com/x/ script-path=https://raw.githubusercontent.com/MeetaGit/MeetaRules/master/Surge/Scripting/bili.js

主机名添加：app.bilibili.com

[MITM]

hostname = app.bilibili.com

下面是官方文档的介绍。emmm，居然是中文的。。。

Scripting

(The document is in Chinese during beta testing)

从 Surge Mac 3.2.0 开始，可以使用 JavaScript 来对 response body 进行修改。配置如下

[Script]
http-response .* script-path=anti-spoiler.js

每一行配置分为三个部分，第一部分为脚本类型，目前仅支持 ‘http-response’； 第二部分为针对请求 URL 的正则表达式； 第三部分为参数表，使用半角逗号分隔，参数有：

• script-path：JS 脚本的路径，可以是 URL、相对路径或绝对路径（仅限 macOS），必填。
• script-update-interval：JS 脚本的更新间隔，仅当使用 URL 时生效，选填，默认值为 24 小时。
• max-size：最大允许进行修改的 body 大小，单位为字节，选填，默认值为 524288 (512KB)。

由于进行 script 修改会需要 Surge 先将 response body 完全下载后再进行处理，如果遇到了较大的数据将导致内存占用量暴增，Surge iOS 受系统内存限制在该情况下极易被直接终止。

当返回的数据长度超过 max-size 设定值后，Surge 将放弃对该请求执行脚本并回退到 passthrough 模式。

编写脚本

Surge 会向 JSVM 上下文传入以下全局变量：

• body[String]: 原始 response body
• status[Number]: HTTP 状态码
• method[String]: HTTP 请求方法
• url[String]: URL 地址

Surge 将使用脚本的最后一行运行结果作为返回值，返回值约定如下：

• String 类型: 将使用该结果作为新的 response body
• Null: 终止该请求
• undefined: 不对请求进行修改

一个简单的样例

var obj = JSON.parse(body); // 对 response body 进行 JSON 解析得到 Object
obj['surge'] = 'OK';  // 增加 'surge' 字段
JSON.stringify(obj); // 进行 JSON 编码并作为结果返回

另一个样例，将全文查找所有的文字进行反剧透https://gist.github.com/Blankwonder/72fcdd46d1d9148f5461c6b59d859551

其他

• 受 JavaScript 语言限制，目前仅支持对 UTF-8 编码的 response body 执行脚本，如果 response body 的二进制数据无法进行 UTF-8 解码，将跳过脚本直接返回。
• 默认情况下，每次执行脚本时将使用一个干净的 JVM 上下文，如果需要可配置

[General]
shared-jvm-context=true

该模式下所有脚本将共享上下文，可以使用全局变量共享数据。

• 可使用 console.log 将日志输出到 Surge 的日志中，方便调试。
• Dashboard 中抓到的 response header 和 response body 为修改后的结果，在 Notes 中可看到脚本的执行情况。

补充一点

在 iOS 系统中使用本地 js 时，.js文件无法像.list文件一样通过拷贝粘贴到 iCloud 云盘 Surge 文件夹中

解决方法：

• 通过 MAC 系统保存文件到相应路径
• 不使用.js作为文件后缀名，.txt、.list都可以，在 Surge 中引用时注意后缀名需一致
• 壮壮又发现可以移动整个文件夹到 Surge 文件夹中，真是迷呀

另外，若是 Surge 文件夹中的外部资源较多，可以在 Surge 文件夹中建立专用的文件夹，引用时注意路径即可。如：

└── iCloud云盘
    └── Surge
        ├── zhuangzhuang.conf
        ├── lhie1.conf
        ├── sconper.conf
        └── resources           // 用于存放外部资源
            ├── policy          // 用于存放策略组
            │   ├── auto.list
            │   ├── all.list
            │   └── clash.list
            ├── ruleset         // 用于存放规则集
            │   ├── ad.list
            │   └── cn.list
            └── js              // 用于存放js脚本
                ├── wb_rm_ad.js
                └── fang-ju-tou.js

在 Surge 中引用

[Proxy Group]
🛥 Select = select, policy-path=resources/policy/all.list

[Rule]
RULE-SET,resources/ruleset/cn.list,🛥 Select

[Script]
http-response api.weibo.cn script-path=resources/js/wb_rm_ad.js

不维护规则和脚本！！！

这是我上一家公司的案例总结，发现躺在草稿箱好几个月了，今天得空就整理发布一下。

先说一下开发那边提来的2个case：

①、同一个域名需要反向代理到前台和后台（不同机器和端口）；

②、需要采用IP+端口的模式，嵌入到APP作为DNS污染后的备选方案。

对于第①个问题，很好解决：通过区分二级目录来反代不同的节点即可，所以代码类似如下：

server {
        listen 80;
        server_name demo.domain.com;
        #通过访问service二级目录来访问后台
	location /service/ {
            #DemoBackend1后面的斜杠是一个关键，没有斜杠的话就会传递service到后端节点导致404
            proxy_pass      http://DemoBackend1/;
            proxy_redirect  off;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
        #其他路径默认访问前台网站
        location / {
            proxy_pass http://DemoBackend2;
            proxy_redirect  off;
            proxy_set_header  Host  $host;
            proxy_set_header  X-Real-IP  $remote_addr;
            proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
        }
    }

#简单的负载均衡节点配置
upstream DemoBackend1 {
     server 192.168.1.1;
     server 192.168.1.2;
     ip_hash;
 }
upstream DemoBackend2 {
     server 192.168.2.1;
     server 192.168.2.2;
     ip_hash;
}

如上配置即可实现通过一个域名来反代不同的后端节点，用到的思路就是匹配二级目录来反代。

对于第②个问题，可能粗略一看，还没理解是个啥意思吧！

其实就是现在业界流行的一种防DNS污染的解决方案之一：手机APP里面除了通过域名来获取数据，还会额外嵌入一些备用的IP。APP在获取数据时，会先通过域名向服务器发起一个简单的校验请求，如果得到的不是预期数据，说明该网络环境下的DNS已被污染，比如被运营商劫持，请求A内容却给你展示B内容！这时候，APP将会启动备用预案，通过IP的方式来请求数据！很明显，这个做法可以有效避免恶心的DNS劫持了（看完这段是不是有所收获呢？）。

做法很简单，就是在APP中集成多个IP和端口作为备用的访问途径。

当开发GG找到我，提出的需求是：

需要实现公网IP+端口来访问，比如邮件API使用 http://192.168.1.10:125

Ps：公网服务器是多线的，那么就有多个IP，本文假设电信是192.168.1.10，联通是192.168.2.10，移动是192.168.3.10等

说白了就是要用端口来区分不同的API，此时如果我不深究，顺手可能会写出如下配置：

#API1
server {
        listen 125;
        server_name 192.168.1.10 192.168.2.10 192.168.3.10;
        location / {
            proxy_pass      http://DemoBackend;
            proxy_redirect  off;
            proxy_set_header   Host  api1.domain.com;
            proxy_set_header   X-Real-IP   $remote_addr;
            proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        }
}
#API2
server {
        listen 126;
        server_name 192.168.1.1 192.168.2.1 192.168.3.1;
        location / {
            proxy_pass      http://DemoBackend;
            proxy_redirect  off;
            proxy_set_header   Host  api2.domain.com;
            proxy_set_header   X-Real-IP   $remote_addr;
            proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        }
}
##API n等等....

粗略一看，确实是可以实现开发GG的要求啊！再仔细一想，你会发现如此做法会开放越来越多的端口！运维成本以及辨识度低还只是其次，咱说好的安全第一呢？

经过思考和测试，我写出的最终配置如下：

#新增的IP映射配置
server {
        listen 80;
        server_name 192.168.1.10 192.168.2.10 192.168.3.10;
        location /mail_api/ {
            proxy_pass      http://DemoBackend/; #后面的斜杠不能少，作用是不往后端传递/mail-api 这个路径
            proxy_redirect  off;
            proxy_set_header  Host  mailapi.domain.com; #传递不同的host给后方节点，实现IP和域名均可以访问
            proxy_set_header  X-Real-IP  $remote_addr;
            proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
        }
        location /other_api1/ {
            proxy_pass      http://DemoBackend/; 
            proxy_redirect  off;
            proxy_set_header  Host  otherapi1.domain.com;
            proxy_set_header  X-Real-IP  $remote_addr;
            proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
        }
        #还可以添加更多映射，通过不同的路径来映射不同的API，最后对于直接访问IP则返回403，防网络上的扫码探测
	location / {
	    return 403;
	}
}

#原有的域名映射
server {
     listen 80;
     server_name mailapi.domain.com;
     location / {
	    proxy_pass      http://DemoBackend;
            proxy_redirect  off;
            proxy_set_header  Host  $host;
            proxy_set_header  X-Real-IP  $remote_addr;
            proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
	}
}
server {
     listen 80;
     server_name otherapi1.domain.com;
     location / {
	    proxy_pass      http://DemoBackend;
            proxy_redirect  off;
            proxy_set_header  Host  $host;
            proxy_set_header  X-Real-IP  $remote_addr;
            proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
	}
}
#简单的节点配置（当这些API都用到同一个Backend时，上述代码中的proxy_set_header传递的host就起到了关键性作用！）
upstream DemoBackend {
     server 192.168.10.1;
     server 192.168.10.2;
     ip_hash;
 }

最终实现的效果就是：你要通过IP请求邮件API，只要请求 http://192.168.1.1/mail_api/ 即可，而不需要开放多余端口。而且，后续要新增更多API，只需要定义不同的二级路径即可，这些二级路径的辨识度可比端口要好得多！

Ps：正如代码中的注释，示例代码只用了一个 DemoBackend 节点配置，为的是分享另一个小技巧：当后端节点承载了多个站点而且都是监听80端口时（比如某些小公司同一个IIS服务器部署了N个站点），反向代理中的proxy_set_header参数，可以自定义传递一个host域名给后端节点，从而正确响应预期内容！

这段解释有点无力，还是拿实际例子举例吧！

我之前供职的公司节点用的是IIS服务器，前端用Nginx反向代理，IIS服务器上有多个站点，站点之间部分会通过 rewrite 规则联系起来。

打个比方：比如A网站有个专题内容（www.a.com/zt/）是通过IIS伪静态映射到了B网站(content.b.com)。也就是访问到http://www.a.com/zt/，其实最后是通过A网站映射到了B网站上面。

后来发现IIS有个伪静态BUG，会经常奔溃，就要我用前端的Nginx来实现直接映射，而不再走IIS的A网站中转。

那么这个需求就正好用到了 proxy_set_header 技巧，一看就懂：

server {
     listen 80;
     server_name www.a.com;
     location /zt/ {
	    proxy_pass      http://ABackend; #都是相同的节点，此示例代码我就不写upstream了
            proxy_redirect  off;
            proxy_set_header  Host www.b.com; #这里就是关键性作用，传递b域名给后端IIS
            proxy_set_header  X-Real-IP  $remote_addr;
            proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
	}
}

#upstream略..

很明显，通过传递自定义域名，就可以实现通过A网站访问Nginx，返回B网站内容，和反向代理谷歌的原理是一致的。

当然，上文为了实现 IP 和域名都可以访问，这个proxy_set_header 设置也是必须的。说白了就是在反代过程中，对后端服务器伪装（传递）了一个自定域名，让后端响应该域名预期内容。