- 网络
网络
- 绕墙
- 网络问题定位
网络
电信IPv6的一些特征
-
电信IPv6的一些特征
-
电信 IPv6 的一些特征
国内已经全面铺开 ipv6 使用, ipv6 地址池足够大, 个人的每个设备都可以获取到一个 ipv6 地址.
家庭用户使用时需要全栈设备都支持 ipv6 才能最终使用到 ipv6, 由于已经推了很多年, 目前来说 2016 年以后买的设备基本都支持 ipv6 了.
全栈设备包括: 城域设备->小区路由->家庭路由(光猫,路由器)->终端设备(手机,电脑,电视等)
这里不讨论标准的 ipv6 协议, 只讨论电信的 ipv6 的一些特征.
地址分配
首先是地址分配方式, ipv6 有三种分配方式: 静态分配, SLAAC, DHCPv6.
湖北电信使用的是 SLAAC, 也就是说电信的 ipv6 地址是由设备自动分配的, 由于电信的 ipv6 地址池足够大, 所以不会出现地址冲突的问题.
电信 ipv6 地址是随机分配的, 24 小时后重新分配. 如果要从外部访问, 必须使用 DDNS 服务.
防火墙
目前可以发现常见的80, 139, 445等端口已对齐 ipv4 防火前已经都封了, 这非常容易理解, 运营商级的防火墙确实能保护到缺乏网络安全意识的普通用户. 2020 年时电信 ipv6 都是开放的, 现在已经封了一些常用端口.
443端口在电信网内偶尔开放, 但对移动联通不开放. 开发者应注意这一点. 在开发环境测试好的服务, 甚至电信网路手机也能访问, 但移动手机网络却访问不了.
基于简单的防火墙测试, 建议开发者牢记对运营商防火墙的不信任, 选择一个5 位数的端口提供服务.
另外, 电信防火墙没有屏蔽22端口, Windows 的远程桌面服务端口3389也没有屏蔽.
也就是可以远程登录控制, 这会导致一些风险.
攻击者获取到 IP 或者 DDNS 域名后, 就可以开始展开针对攻击, 利用暴力破解的方式获取到密码, 从而获取到控制权, 域名也会暴露一些个人信息, 例如姓名, 住址等, 也可能利用社会工程学的方式获取到更多信息以加快破解速度.
建议关闭 ssh 的密码登录, 仅使用密钥登录, 或者使用 VPN 的方式进行远程登录, 或者使用跳板机的方式进行远程登录.
为什么不应该把TCP思维套在UDP上
- 为什么不应该把TCP思维套在UDP上
为什么不应该把 TCP 思维套在 UDP 上?
结构差异
TCP 上的概念很多: 建立通路, 资源使用, 数据传输, 可靠传输, 基于重复累计确认的重传, 超时重传, 校验和, 流量控制, 拥塞控制, 最大分段大小, 选择确认, TCP 窗口缩放选项, TCP 时间戳, 强制数据递交, 终结通路.
以上这些能力, UDP 基本上都没有, 它仅比链路层多一点区分应用层目的的能力. UDP 足够简单意味着足够灵活.
如果可能发生,则一定会发生
墨菲定律:
如果有多过一种方式去做某事，而其中一种方式将导致灾难，则必定有人会这样选择。
通常介绍 UDP 适合应用在游戏/语音/视频等场景, 少量的错包不影响业务. 为什么 UDP 适合这些场景? 它能用在这些场景, 不代表它是这些场景的最优方案, 必然是存在 TCP 无法解决的问题, 才让这些服务选择了功能简陋的 UDP 协议. 错包不影响业务扩展开来讲是指 TCP 协议在乎错包, UDP 不在乎错包, 更在乎实时性/连续性. UDP 的特点就是它不在乎 TCP 在乎的因素, 这些因素影响了实时性.
在代码实现上, UDP 只需要创建一个 socket, 绑定到一个端口上, 即可以开始收发. 通常 socket 用完时, 端口也用完了.
因此我可以这样使用 UDP:
- 往任意 IP 的任意端口发送随机报文, 看看哪个端口有响应
- 甲通过 A 端口, 将请求报文发送到乙的 B 端口; 乙将响应报文用 C 端口, 发给甲的 D 端口
- 甲通过 A 端口, 将请求报文发送到乙的 B 端口; 乙委托丙将响应报文用 C 端口, 发给甲的 D 端口
- 甲通过 A 端口, 将请求报文发送到乙的 B 端口, 但将发送报文的源 IP 修改为了丙的 IP, 乙将会将响应报文发往丙
- 双方协商各用 10 个 UDP 端口, 同时进行接受和发送
这些方法在 TCP 里自然是行不通的, 但在 UDP 协议中, 只要可以这样做, 就一定会有人这样做. 所以当把 TCP 的一些思维套在 UDP 上是一种理想主义, 真实情况常常不是我们能枚举完的.
UDP 的报文非常简单, 使用也非常灵活, 原本没有连接的概念, 需要自己定义 UDP 连接. 尝试了一些定义方法, 都不能完全准确达到连接方向判断意图, 这时需要接纳一些容错, 毕竟原本就没有 UDP 连接的定义, 当各方对 UDP 连接的定义不一致时, 必然会导致行为与预期不一样.
客户端视角的 UDP
语音/视频等业务常会产生丢包, 但是丢包方式的不同对业务有着不同的影响. 比如 30%的丢包是均匀发生的, 还是全丢在某个时间段, 对体验的影响有明显的区分. 显然, 我们期待的是更均匀的丢包. 可是 UDP 没有流量控制防止方法, 如何丢包则有一些方法. 尽管 UDP 通信常被描述为"尽力而为", 但是不同方式的"尽力"会达到不同的效果.
服务商视角的 UDP
如果是 TCP 攻击, 客户端需要一定的开销, 创建连接, 维护连接, 也就是攻击者需要付出一定的代价. 而在 UDP 攻击中, 攻击者付出的代价小很多, 如果攻击者想消耗的就是服务方的带宽流量, UDP 是一个很好的方式. 比如说服务购买了 100GB 的不限速流量, 处理能力仅 10MB 每秒, 但接受速度 1GB 每秒, 那么 90%的请求流量无效, 但这些流量不是免费的. 服务方应该避免产生这种情况.
运营商的视角的 UDP
完成一次通信需包含多个终端以及通信通道, 受关注的总是服务端和客户端, 其实运营商的视角同样重要. DDoS 攻击中, 我们常关心服务端的资源消耗情况, 实际上运营商的资源也是有限的, 服务端简单不响应请求, 但接收流量却已经消耗了带宽, 只是这个资源一般属于运营商. 我们在压力测试中常用到"丢包率"指标, 这个指标表达的完整通信链条中的丢包, 而不仅仅是服务端的丢包. 运营商也会丢包. 在运营商看, 服务方仅购买了 1MB/s 的带宽, 但客户端以 1GB/s 的速度发送, 双方都不必为浪费的流量付费, 是运营商承担了这部分带宽的代价. 因此, 运营商必然想办法屏蔽这种流量, 也就是 UDP 的 QoS. 在 TCP 中有拥塞控制, 但在 UDP 中, 运营商可以通过丢包来控制流量. 实际情况中, 运营商更加简单粗暴, 直接屏蔽长时间使用的端口的流量, 也就是 UDP 的端口屏蔽. 在微信通话的实际测试中发现, 每一通电话客户端会使用多个端口, 其中有一个 UDP 端口会和同一服务器的 6 个 UDP 端口进行通信, 推测就是为了应对运营商的端口屏蔽.
总结
UDP 的灵活表示在实现一个目标时, 它有着多种实现方式, 并且都是合法的, 只要能最终实现稳定的通信, 不管它实现的如何和 TCP 大相径庭, 都是"存在即合理"的. 因而, 我们不能完全将 TCP 的概念套用在 UDP 上, 即便为了产品设计, 创造了新的 UDP 连接定义, 也应该能预期并允许出错, 毕竟"允许出错"就是 UDP 的核心功能, 这是 UDP 的优势, 不是它的缺点, 是服务主动选择的协议核心能力, 而不是不得不接受的缺点.
更多阅读
linux网络问题定位
排障工具
| 工具 | 说明 | 用法 | 说明 |
|---|---|---|---|
| ping | 测试网络连通性 | ping baidu.com | |
| traceroute | 路由跟踪 | traceroute ip | |
| route | 路由表 | route -n | |
| netstat | 网络连接 | netstat -ano | |
| nslookup | DNS 解析 | nslookup baidu.com | |
| ifconfig | 网络配置 | ifconfig | |
| arp | ARP 缓存 | arp -a | |
| nbtstat | NetBIOS | nbtstat -n | |
| netsh | 网络配置 | netsh | |
| net | 网络配置 | net | |
| tcpdump | 网络抓包 | tcpdump | |
| wireshark | 网络抓包 | wireshark | |
| ip | 网络配置 | ip addr show | |
| ss | 网络连接 | ss -tunlp | |
| netstat | 查看网络连接状态 | netstat -anp | |
| tcpdump | 抓包工具 | tcpdump -i eth0 -nn -s 0 -c 1000 -w /tmp/tcpdump.pcap | |
| iptables | 防火墙 | iptables -L -n -v -t nat -t mangle -t filter | |
| ss | netstat 的替代品 | ss -anp | |
| ifconfig | 查看网卡信息 | ifconfig eth0 | |
| ip | 查看网卡信息 | ip addr show eth0 | |
| route | 查看路由表 | route -n | |
| traceroute | 查看路由跳数 | traceroute www.baidu.com | |
| ping | 测试网络连通性 | ping www.baidu.com | |
| telnet | 测试端口连通性 | telnet www.baidu.com 80 | |
| nslookup | 域名解析 | nslookup www.baidu.com | |
| dig | 域名解析 | dig www.baidu.com | |
| arp | 查看 arp 缓存 | arp -a | |
| netcat | 网络调试工具 | nc -l 1234 | |
| nmap | 端口扫描工具 | nmap -sT -p 80 www.baidu.com | |
| mtr | 网络连通性测试工具 | mtr www.baidu.com | |
| iperf | 网络性能测试工具 | iperf -s -p 1234 | |
| iptraf | 网络流量监控工具 | iptraf -i eth0 | |
| ipcalc | IP 地址计算工具 | ipcalc | |
| iftop | 网络流量监控工具 | iftop -i eth0 | |
| iostat | 磁盘 IO 监控工具 | iostat -x 1 10 | |
| vmstat | 虚拟内存监控工具 | vmstat 1 10 | |
| sar | 系统性能监控工具 | sar -n DEV 1 10 | |
| lsof | 查看文件打开情况 | lsof -i:80 | |
| strace | 跟踪系统调用 | strace -p 1234 | |
| tcpflow | 抓包工具 | tcpflow -i eth0 -c -C -p -o /tmp/tcpflow | |
| tcpick | 抓包工具 | tcpick -i eth0 -C -p -o /tmp/tcpick | |
| tcptrace | 抓包工具 | tcptrace -i eth0 -C -p -o /tmp/tcptrace | |
| tcpslice | 抓包工具 | tcpslice -i eth0 -C -p -o /tmp/tcpslice | |
| tcpstat | 抓包工具 | tcpstat -i eth0 -C -p -o /tmp/tcpstat | |
| tcpdump | 抓包工具 | tcpdump -i eth0 -C -p -o /tmp/tcpdump | |
| tshark | 抓包工具 | tshark -i eth0 -C -p -o /tmp/tshark | |
| wireshark | 抓包工具 | wireshark -i eth0 -C -p -o /tmp/wireshark | |
| socat | 网络调试工具 | socat -d -d TCP-LISTEN:1234,fork TCP:www.baidu.com:80 | |
| ncat | 网络调试工具 | ncat -l 1234 -c ’ncat www.baidu.com 80' | |
| netperf | 网络性能测试工具 | netperf -H www.baidu.com -l 60 -t TCP_STREAM | |
| netcat | 网络调试工具 | netcat -l 1234 | |
| nc | 网络调试工具 | nc -l 1234 | |
| netpipe | 网络性能测试工具 | netpipe -l 1234 | |
| netkit | 网络调试工具 | netkit -l 1234 | |
| bridge | 网桥工具 | bridge -s |
如何提升自建DNS服务下的网络体验
网络质量和网络体验
什么都不做, 即可以获得最好的网络体验
需要明确, 这里网络质量和网络体验是两个不同的概念. 通信是一个过程, 涉及多个设备, 我们可以称单个设备的上下行表现为网络质量, 而整个端到端的通信表现, 我们可以称为网络体验.
如何衡量网络质量
衡量网络质量通常涉及多个指标和方法。以下是一些常见的衡量网络质量的方法和指标：
- 带宽（Bandwidth）：带宽是指网络传输数据的能力，通常以每秒传输的数据量（比特/秒）来衡量。更高的带宽通常表示更好的网络质量。
- 延迟（Latency）：延迟是指数据从发送端到接收端所需的时间。低延迟表示数据传输速度快，网络响应更快。
- 丢包率（Packet Loss Rate）：丢包率是指在数据传输过程中丢失的数据包的比例。较低的丢包率通常意味着网络质量较好。
- 抖动（Jitter）：抖动是指数据包在传输过程中的变化或波动。较小的抖动表示网络稳定性较高。
- 吞吐量（Throughput）：吞吐量是指网络传输的实际数据量，通常以单位时间内的数据传输量来衡量。更高的吞吐量表示网络质量更好。
- 网络拓扑（Network Topology）：网络拓扑描述了网络中节点之间的连接方式和结构。合理的网络拓扑设计可以提高网络性能和质量。
- 服务质量（Quality of Service，QoS）：QoS 是一组技术和机制，用于确保在网络中的数据传输中实现可接受的服务质量。QoS 可以通过各种方式实现，包括流量控制、优先级队列等。
- 网络协议分析（Protocol Analysis）：通过分析网络协议和数据包，可以了解网络中的性能指标和问题，例如使用 Wireshark 等网络分析工具。
综合利用这些指标和方法，可以全面地评估网络质量，确定网络性能的优势和改进的空间。 但这些是运营商关注的指标, 对于普通用户, 只需要购买价格合适的路由器即可, 现代路由器都有自动调整网络质量的功能.
如何衡量网络体验
首先是可访问性, 能访问是最重要的基础. 因此, 域名解析服务需要满足基础的能力:
- 全面, 上级 DNS 服务需要权威, 且能够解析更多的域名
- 正确, 解析结果需要正确, 不能出现解析错误. 部分 DNS 服务商会对一些域名进行劫持或污染, 解析到广告页面.
- 及时, ip 地址变更后, 需要及时更新解析结果, 而不是返回旧的 ip 地址
其次是 DNS 解析结果的 IP 所能提供服务的网络质量.
互联网服务所能提供的网络质量, 通常强依赖地域, 服务器和客户端在地域上越接近, 则服务质量越好.
许多付费 DNS 解析服务商都支持按地域解析不同 IP, 例如这是阿里云能提供的一部分服务:
（1）运营商线路：支持按联通、电信、移动、教育网、鹏博士、广电网智能解析，细分到省份；
（2）海外地区线路：支持，细分到大洲、国家；
（3）阿里云线路：支持，细分到各个地区；
（4）自定义线路：支持自定义 IP 地址范围智能解析；
按区域解析不同 IP 的机制, 意味着不同地域的用户访问同一个域名时, 会得到不同的解析结果, 自然而然的, 优先解析到距离用户更近的服务器, 将会有更好的网络体验.
而优化用户网络体验这件事, 一般都是服务提供商根据用户的真实 IP 地址来做优化. 也就是对多数用户来说, 什么都不做, 即可以获得最好的网络体验.
自建 DNS 服务如何选择上游 DNS 服务
中文互联网你搜索到的所有资料都会推荐你选择权威 DNS 服务商, 例如阿里云, 腾讯云, Cloudflare, 谷歌等. 这些 DNS 可以满足网络服务的的可访问性, 因为它们全面/正确/及时, 但是, 它们未必会给你解析到最近的服务器 IP.
互联网上大量的资料推荐大企业的 DNS 服务有其历史原因.
曾经我国的 ISP 运营商, 仅靠 DNS 劫持加上 HTTP 的中间人攻击, 就能够实现对用户的流量劫持, 从而实现广告推送. 现如今随着 https 的普及, 这种劫持方式已较为少见, 但部分地区的小区宽带仍然可能存在这种问题. 针对 DNS 劫持问题, 实际上改 DNS IP 无济于事, 因为劫持可以针对 53 端口, 而绝大多数 DNS 请求都是未加密的.
此外, 一些特殊用户希望访问特殊网站, 而部分 DNS 服务商存在 IP 污染问题, 会将特殊网站的域名解析到错误的 IP 地址, 导致无法访问. 而权威 DNS 服务商则较少出现这样问题.
因此, 这里存在三个问题需要考虑:
- IP 污染
- DNS 劫持
- 最优服务体验
权威 DNS 服务商可以解决问题 1 , 加密协议(DoT/DoH/QUIC)可以解决问题 2.
想要解决问题 3, 你需要使用回宽带运营商的默认 DNS 服务., 正如本文开头所说, 什么都不做, 即可以获得最好的网络体验.
但如果你是一个有追求的人, 或者特殊用户, 下文将介绍如何配置 AdguardHome 及 Clash 两种工具的配置, 以同时解决这三个问题.
权威且智能的 DNS 服务
AdguardHome 配置
AdguardHome, 以下简称ADG 是一个网络广告拦截与隐私保护软件, 也是一个 DNS 服务. 它支持自定义上游 DNS 服务, 以及自定义 DNS 规则.
ADG 默认的向上游请求 DNS 的方式是负载均衡, 用户可以设置多个上游, ADG将根据历史 DNS 查询加权权重选择其中 DNS 响应最快的上游. 简单说, ADG 会以更高的概率选择更快的 DNS 上游来解析域名, 以较低的概率选择非最优的 DNS 上游.
我们可以选择第三个选项: 最快的IP地址.
该选项带来的好处, ADG自行测试上游 DNS 的 IP 解析结果, 将其中延迟最低的 IP 返回给下游客户端. 以下是bilibili的常规解析结果.
你可以看到 IP 非常多, 如果ADG不测试 IP 解析结果, 而将所有 IP 返回给客户端, 那么客户端会做什么?
有的客户端会选择第一个 IP, 有的客户端会选择最后一个 IP, 有的客户端会随机选择一个 IP. 不管是哪种, 都未必是最优的选择.
开启最快的IP地址选项后, 以下是bilibili的优选解析结果, 这一步将会带来网络体验的提升.
最快的IP地址为什么不是默认选择? 这个功能这么实用, 为什么不默认开启?
因为它的代价是等待所有上游 DNS 的 IP 解析结果, 当你的上游同时有多个 DNS 服务商时, 向上游的查询时间以其中最慢的为准. 例如, 你的上游有平均服务时长50ms的阿里和平均服务时长500ms谷歌, ADG的上游查询时间将是500ms+.
因此用户在配置此选项时, 需要权衡上游 DNS 的服务质量和数量, 不要贪多.
这里我推荐设置两个上游, 一个权威(https://dns.alidns.com/dns-query), 加上一个运营商 DNS.
运营商的 DNS IP 各地都不相同, 可以点击这里查看自己所在地区的运营商 DNS.
或者, 你可以在路由器的管理界面上查看运营商推荐的 DNS :
Clash 配置
特殊需求用户看重 DNS 劫持和 IP 污染问题, 但又不想放弃最优服务体验, 可以使用Clash的dns模块.
其中nameserver-policy可以指定不同的域名使用不同的 DNS 服务商, 以下是一个示例配置:
dns:
default-nameserver:
- tls://223.5.5.5:853
- tls://1.12.12.12:853
nameserver:
- https://dns.alidns.com/dns-query
- https://one.one.one.one/dns-query
- https://dns.google/dns-query
nameserver-policy:
"geosite:cn,private,apple":
- 202.103.24.68 # 自己所在地的运营商 DNS
- https://dns.alidns.com/dns-query
"geosite:geolocation-!cn":
- https://one.one.one.one/dns-query
- https://dns.google/dns-query
它的含义是:
- default-nameserver: 用于解析配置
nameserver中的 DNS 服务的 IP - nameserver: 用于解析网络请求的域名
- nameserver-policy: 根据策略, 指定不同的域名使用不同的 DNS 服务
感谢阅读
如果本文对您有所帮助, 还请点个赞. 也非常欢迎留言讨论.
ChatGPT VPN识别绕过方法
如何处理 ChatGPT 报错
“Unable to load site”
“Please try again later, if you are using a VPN, try turning it off.”
“Check the status page for information on outages.”
前言
chatgpt 目前仍然是使用体验最好的聊天机器人，但是在国内使用时，由于网络环境的限制，我们需要使用梯子来访问 chatgpt。但是 chatgpt 对梯子的检测较为严格，如果检测到使用了梯子，会直接拒绝访问。这里介绍一种绕过 chatgpt 对梯子检测的方法。
有其他人提到更换 IP 来绕过封锁, 但我们一般使用 IP 的地域已经是可以提供服务的地区, 所以这种方法并不一定是实际的拒绝服务原因.
另外有人提到梯子使用人数较多容易被识别, 劝人购买较贵的使用人数少的梯子, 这也很难成为合理理由, 在 ipv4 短缺的今天, 即便是海外, 也存在大量的社区使用 nat 分配端口, 共用一个 ipv4 的情况. chatgpt 一封就要封一大片, 作为一个被广泛使用的服务, 这样的检测设计肯定是不合理的.
对大众服务来说, 检测源 IP 一致性则更为合理. 付费梯子的特征通常是限制流量或限制网速, 因此多数使用梯子的用户选择按规则绕过. 绕过自己的运营商可直接访问的地址, 以减少流量消耗, 或者获得更快的访问速度, 仅在访问被防火墙拦截的地址时导入流量到代理. 这种访问目标服务的不同方式, 可能会造成源地址不一致. 例如访问 A 服务需要同时和域名 X 和域名 Y 进行通信, 而防火墙仅拦截了域名 X, 那么在 A 服务看到的同一请求的不同阶段的访问来源 IP 不一致.
解决代理策略导致的源 IP 不一致问题, 即可绕过 chatgpt 的梯子识别.
梯子规则中通常会含有域名规则, IP规则等.
我们还需要知道域名解析的 IP 结果是可以根据地域而变化的, 比如我在 A 地区时解析到附近的服务 IP, 在 B 地区时则解析到不同的 IP. 因此, DNS 的选择也非常重要.
DNS 选择
现在 DNS 有很多的协议, UDP:53 已经是非常落后而且极不安全的协议, 我国甚至已将 DNS 服务列入企业经营中的一级条目. 这主要来源于过去几十年我国的各级运行商使用DNS劫持加HTTP塞入了大量的跳转广告, 蒙骗不少网络小白, 招致大量投诉. 尽管现在Chrome/Edge已经标配自动跳转HTTPS, 标记HTTP网站为不安全, 但我国还存在许多的地方小区级的网络服务提供商, 以及国内各种老版本的Chromium封装魔改, 导致 DNS 劫持和 HTTP 劫持仍然存在.
因此, 我们需要选择一个安全的 DNS 服务协议, 以避免 DNS 劫持. 根据个人经验, 阿里云的223.5.5.5体验足够好. 当然, 当我提223.5.5.5时, 肯定不是UDP:53的 alidns, 而是DoH或DoT协议. 在配置时, 你需要使用tls://223.5.5.5, 或者https://dns.alidns.com/dns-query写入配置.
alidns 服务在绝大多数时候都不会污染, 仅在少数敏感时期会出现污染, 你也可以使用我自建的长期 dns 服务tls://dns.jqknono.com, 上游来自8.8.8.8和1.1.1.1, 通过缓存来加速访问.
域名规则
首先打开的检测网页会包含检测逻辑, 通过向不同域名发送请求来验证源 IP, 因此这里需要保持域名代理的一致性.
chatgpt 网页访问的域名除了自己的域名openai外, 还有auth0, cloudflare等第三方域名.
可以手动写入以下规则:
# openai
- DOMAIN-SUFFIX,chatgpt.com,PROXY
- DOMAIN-SUFFIX,openai.com,PROXY
- DOMAIN-SUFFIX,openai.org,PROXY
- DOMAIN-SUFFIX,auth0.com,PROXY
- DOMAIN-SUFFIX,cloudflare.com,PROXY
如何试验域名规则
上边列举的域名可能随着 ChatGPT 业务发展而有所变化, 下面说明域名的获取方法.
- 浏览器打开 InPrivate 页面, 隐私页面可以避免缓存/cookies 等的影响
- 按
F12打开控制台, 选择Network/网络选项卡 - 访问
chat.openai.com, 或者chatgpt.com - 下图展示了这篇文章写成时 ChatGPT 使用的域名
仅添加这几个域名可能仍然不够, 这里分析访问失败的连接具体细节. 看到challenge的请求的Content-Security-Policy中含有众多域名, 我们将其一一添加到代理策略.
# openai
- DOMAIN-SUFFIX,chatgpt.com,PROXY
- DOMAIN-SUFFIX,openai.com,PROXY
- DOMAIN-SUFFIX,openai.org,PROXY
- DOMAIN-SUFFIX,auth0.com,PROXY
- DOMAIN-SUFFIX,cloudflare.com,PROXY
# additional
- DOMAIN-SUFFIX,oaistatic.com,PROXY
- DOMAIN-SUFFIX,oaiusercontent.com,PROXY
- DOMAIN-SUFFIX,intercomcdn.com,PROXY
- DOMAIN-SUFFIX,intercom.io,PROXY
- DOMAIN-SUFFIX,mixpanel.com,PROXY
- DOMAIN-SUFFIX,statsigapi.net,PROXY
- DOMAIN-SUFFIX,featuregates.org,PROXY
- DOMAIN-SUFFIX,stripe.com,PROXY
- DOMAIN-SUFFIX,browser-intake-datadoghq.com,PROXY
- DOMAIN-SUFFIX,sentry.io,PROXY
- DOMAIN-SUFFIX,live.net,PROXY
- DOMAIN-SUFFIX,live.com,PROXY
- DOMAIN-SUFFIX,windows.net,PROXY
- DOMAIN-SUFFIX,onedrive.com,PROXY
- DOMAIN-SUFFIX,microsoft.com,PROXY
- DOMAIN-SUFFIX,azure.com,PROXY
- DOMAIN-SUFFIX,sharepoint.com,PROXY
- DOMAIN-SUFFIX,gstatic.com,PROXY
- DOMAIN-SUFFIX,google.com,PROXY
- DOMAIN-SUFFIX,googleapis.com,PROXY
- DOMAIN-SUFFIX,googleusercontent.com,PROXY
IP 规则
如果上述步骤尝试后仍然不能访问chatgpt.com, 则可能还存在基于IP的检测行为, 以下是我在连接跟踪中尝试出的一些 IP, 你可以自行尝试使用, 需要说明这些 IP 并不一定适用于每个地区, 你或许需要自行尝试.
# openai
- IP-CIDR6,2606:4700:4400::6812:231c/96,PROXY
- IP-CIDR,17.253.84.253/24,PROXY
- IP-CIDR,172.64.152.228/24,PROXY
- IP-CIDR,104.18.35.28/16,PROXY
如何试验 IP 规则
你需要了解自己的梯子客户端工具, 在连接跟踪显示页面, 观察新增的连接, 通过这些连接的 IP 地址来尝试添加规则.
以下是简单的步骤描述:
- 浏览器打开 InPrivate 页面, 隐私页面可以避免缓存/cookies 等的影响
- 访问
chat.openai.com, 或者chatgpt.com - 梯子客户端中观察新增连接, 将这些连接加入到代理规则
协议规则
QUIC是基于UDP的加密协议, chatgpt 大量使用了 QUIC 流量, 因此梯子的服务端/客户端需要支持 UDP 代理, 有许多梯子是不支持 UDP 的, 这也是导致 chatgpt 无法访问的原因之一. 客户端和服务端都支持 UDP, 还需要用户明确配置, 一些客户端会配置默认不代理 UDP 流量. 如果对 UDP 设置不熟悉, 可以设置屏蔽代理客户端的 QUIC 流量, 或者在浏览器设置屏蔽 QUIC. 浏览器发现 QUIC 不通会自动切换到基于 TCP 的 HTTP/2. QUIC 是基于 UDP 的加密协议, 多数时候可以获得更流畅的体验, 有兴趣的可以自行尝试.
最简单配置–白名单模式
配置仅中国 IP 直连, 未匹配到的流量走代理, 这样可以保证 chatgpt 的访问, 也可以保证其他国外服务的访问.
这种方式的缺点就是流量消耗大, 网络流畅度体验依赖梯子的网络质量, 如果您对自己的梯子有信心, 可以尝试这种方式.
当然, 您还得记得开启UDP代理.