2026年HTTPS加密原理与翻墙安全完全指南：TLS握手、证书信任链与中间人攻击，机场到底能看到你什么？

打开任何一个 HTTPS 网站，地址栏都会出现一把小锁。绝大多数人对它的理解止步于「连接是加密的」，但真正值得问的是：这把锁到底锁住了什么，又留下了哪些没锁住的东西？对科学上网用户来说，这个问题尤其关键——你的流量要先经过机场节点，再到达目标网站，中间多了一双「中转的手」。密码会被机场看到吗？HTTPS 是不是绝对安全？公共 Wi-Fi 上的中间人攻击是都市传说还是真实威胁？这篇文章从 TLS 握手讲起，把对称加密、非对称加密、证书信任链一次讲透，最后回答那个最实际的问题：翻墙时，到底谁能看到你的什么。

先记住一个反直觉的结论：HTTPS 保护的是传输内容，不保护你的身份和行踪。它保证「你在网上发的消息没人能偷看」，但不保证「没人知道你在访问什么」。而整套安全链条还有一个物理前提——TLS 握手必须能顺利完成。握手是连接中最脆弱的一环：客户端发出的第一条消息要穿过国际链路到达服务器，任何一次丢包、超时或连接重置，都会让加密无从谈起。这也是为什么科学上网要先解决线路：使用自由猫这类 IEPL 专线机场时，握手报文走的是低延迟、低丢包的专线通道，重试次数少，HTTPS 的安全链条才真正闭合得起来。下面我们从算法层面开始拆解。

一、对称加密：加密内容的「快刀」

现代加密算法分成两大类，第一类是对称加密：加密和解密用同一把密钥。发送方用密钥 K 把明文变成密文，接收方用同一把 K 还原。它的最大优势是快——硬件加速下每秒可以处理数 GB 数据，所以真正传输的内容都是用对称加密来保护的。

对称加密不是「把字母往后挪几位」的凯撒密码，而是经过精心设计的算法。今天 TLS 里最常看到两个：AES-256-GCM 和 ChaCha20-Poly1305。AES 是硬件普遍支持的老牌算法，GCM 是它的工作模式，能在加密的同时生成完整性校验；ChaCha20 是面向纯软件场景设计的流密码，在 ARM 手机和没有 AES 指令集的设备上反而更快，Poly1305 负责完整性。两个都带 GCM/Poly1305 后缀的算法统称 AEAD（带关联数据的认证加密）——「认证」二字意味着它们同时保证机密性和完整性：密文被篡改一个比特，接收方立刻能发现。

为什么完整性重要？因为攻击者如果只能看到密文、改不了内容，他仍然可能把密文「重放」或「拼接」来制造混乱。AEAD 算法把加密和防篡改绑在一起，堵死了这类操作。你在 TLS 1.3 里看到的加密套件 TLS_AES_256_GCM_SHA384、TLS_CHACHA20_POLY1305_SHA256，本质就是「用哪种 AEAD 加密 + 用哪种哈希做密钥派生」的声明。科学上网协议也大量使用同一族算法：Shadowsocks 的 AEAD 加密、WireGuard 的 ChaCha20-Poly1305，都和你浏览器里的 HTTPS 是同门师兄弟。

对称加密只有一个问题：加密和解密必须共用同一把密钥，那这把密钥怎么安全地送到对方手里？如果通过网络直接传，被截获就等于没加密——这就是非对称加密要解决的难题。

二、非对称加密：把公钥交给全世界

非对称加密使用一对数学上关联的密钥：公钥和私钥。公钥可以公开给任何人，私钥只有自己保管。用公钥加密的数据只有私钥能解开；反过来，用私钥签名的数据，任何人都能用公钥验证「这确实出自私钥持有者之手」。它的核心价值是解决了密钥分发：不需要事先偷偷交换密钥，双方就能建立安全通信。

具体到数学实现，主流是两条路线。RSA 依赖大整数分解的困难性：两个大质数相乘很容易，但把乘积分解回质数极难，RSA-2048 至今无人能攻破，但它的密钥和运算都很「重」。椭圆曲线（ECC） 依赖椭圆曲线离散对数问题，同样 128 比特安全强度下，RSA 需要 3072 比特密钥，ECC 只要 256 比特——又短又快。今天你在配置里看到的 X25519、P-256、Ed25519 都属于 ECC 家族：X25519 用于密钥交换，Ed25519 用于签名。REALITY、Hysteria2、WireGuard 这些 2020 年后的协议全部倒向 ECC，原因就是性能和密钥长度的双重优势。

非对称加密也有短板：慢。RSA 做一次私钥运算要消耗毫秒级时间，而对称加密每秒能处理 GB 级数据，两者相差好几个数量级。所以真实世界从不拿非对称加密直接加密正文，而是让它干两件事：密钥交换（双方协商出一个临时的对称密钥）和身份签名（证明公钥确实属于某网站）。这也引出了 TLS 1.3 里一个关键设计——前向保密（PFS）：每次会话都用 ECDHE 临时生成一对一次性密钥，用完即弃。即使某天服务器的长期私钥泄露，攻击者也解不开过去录制的任何一段流量，因为会话密钥早已销毁。TLS 1.3 直接废除了不做前向保密的 RSA 密钥交换，只保留 ECDHE，这是 2018 年以来加密领域最重要的安全升级之一。

三、TLS 握手：一条 HTTPS 连接是怎么「谈成」的

把对称加密和非对称加密组合起来，就是 HTTPS 背后的 TLS 协议。每次连接建立时，客户端和服务器要先完成一次「谈判」，称为 TLS 握手。TLS 1.3 的完整握手只要一个往返（1-RTT），过程大致是：

客户端发送 ClientHello：支持的 TLS 版本、加密套件列表、一个随机数，以及可选的 SNI（告诉服务器自己想访问哪个域名）；
服务器回应 ServerHello：选定加密套件、给出自己的临时公钥（ECDHE 参数），并附上证书（包含网站公钥和 CA 签名）；
客户端验证证书：确认证书链可信、域名匹配、没有过期；
双方各自用「客户端随机数 + 服务器随机数 + ECDHE 临时公钥」算出同一把会话密钥，从此进入对称加密通信。

看到这里你会发现一个容易被忽略的事实：握手阶段客户端只收到服务器的证书，却并不验证服务器的「长相」是否与历史一致——它验证的是证书本身是否可信。这把「信任」问题全部压到了证书体系上，也就是下一节的内容。另外，同一次握手其实有两个可观察维度：一个是「内容」，即密钥怎么协商、证书是否可信（本篇主题）；另一个是「长相」，即 ClientHello 报文的字节特征——这正是 GFW 用来识别翻墙流量的 TLS 指纹，原理详见这篇TLS 指纹识别与伪装指南。

握手对网络质量极其敏感：每一步都是一个网络往返（RTT），而每个往返都要吃一次物理延迟。直连跨境网站时，握手经常因为中间链路丢包而反复重传，表现就是「转圈好几秒才打开」。想直观感受一个 HTTPS 请求的每一毫秒花在哪里，可以对照这篇数据包科学上网之旅里的逐跳拆解。对翻墙用户来说，握手超时还有一个隐蔽后果：很多「连接被重置」其实发生在 TLS 阶段，而不是 TCP 阶段——GFW 对特定目标的 RST 注入，往往打的就是 ClientHello 之后的窗口。这也是为什么晚高峰时，走万达云这类中转+IEPL 组合方案的连接明显更稳：握手往返被放在低丢包率的专线链路上，超时重试大幅减少，TLS 握手能一次走完。

四、证书信任链：浏览器凭什么相信这张证书

非对称加密保证了「只有私钥持有者能解密」，但它回答不了更根本的问题：你怎么知道手里的公钥真的属于目标网站？如果攻击者在中途换掉公钥、用自己的私钥配合，加密照样成立，只是对象错了——这就是中间人攻击的根源。解决「公钥归属」问题的机制，就是数字证书。

一张 X.509 证书的核心内容是：域名、网站公钥、签发者（CA）、有效期和一个数字签名。签名由证书颁发机构（CA）用它的私钥生成，任何人用 CA 的公钥都能验证这张证书没有被篡改。于是信任从「每一张证书」上移到「CA 本身」，形成一条信任链：

根证书（内置在操作系统/浏览器里，如 ISRG Root X1）
   └── 中间 CA 证书（如 Let's Encrypt 的中间证书）
          └── 叶子证书（你访问的网站，如 example.com）

操作系统和浏览器出厂时就内置了一批根证书，它们是人类信任的「锚点」。验证时浏览器沿着证书链逐级回溯，直到找到一个自己信任的根证书，再逐级验证签名，最后检查域名匹配和有效期。任何一个环节失败，浏览器就会亮出「您的连接不是私密连接」的红色警告。

这里有一个反直觉的常识：免费证书比某些收费证书更安全。Let's Encrypt 这类 CA 通过 ACME 协议自动化签发域名验证（DV）证书，只证明「你控制这个域名」，有效期仅 90 天、必须自动续期。免费意味着无人认领的域名不会被用来签发恶意证书——签了也会立刻被证书透明度（CT）日志公开，全网都能看到。真正决定安全级别的不是证书价格，而是私钥有没有泄露、域名验证做没做对。想亲眼看看自己网站的证书链，用 OpenSSL 就能查：

openssl s_client -connect fanqiangdao.com:443 -servername fanqiangdao.com \
  -showcerts < /dev/null 2>/dev/null | grep -E "s:|i:"

输出的每一行代表证书链上的一级，s: 是主体、i: 是签发者。如果你在某个网站看到「证书由未知机构签发」或「证书链不完整」，不要点「继续访问」——那通常意味着网络里有人在做手脚，或是站点本身配置错误。

五、翻墙流量是「双重加密」：协议层与 TLS 各管一段

理解 HTTPS 之后，就能准确回答翻墙场景里最常被问错的问题：「机场是不是能看到我访问的网页内容？」答案取决于流量的结构。一次完整的科学上网请求，数据要经过两段路径，每一段的加密是独立的：

第一段：客户端 → 机场节点。由代理协议加密，比如 Shadowsocks 的 AEAD、VMess、VLESS+TLS、Trojan、Hysteria2、REALITY。这一段加密的主要目的是对抗 GFW 的识别——让中间设备看不出你在翻墙，而不是防机场本身（机场服务器要解密协议头才知道把流量转发到哪）；
第二段：客户端 → 目标网站。这是标准的 HTTPS/TLS，由目标网站控制，端到端穿过机场节点。节点在这段里只是转发密文的管道，手里没有 TLS 会话密钥，自然读不出你提交的表单、密码和 Cookie。

所以严格说，机场看到的是「协议解密后的 TCP 流」，而 TCP 流里是你看不见的 TLS 密文。各家协议对「能看到什么」的差别主要在防检测能力：Trojan 把流量伪装成标准 HTTPS 走 443 端口，REALITY 更进一步借用真实网站的证书做 TLS 1.3 会话复用，Hysteria2 则把传输层换成基于 UDP 的 QUIC 来抗丢包——这些协议的加密与防识别细节，在主流协议对比和Hysteria2 完全指南里有完整拆解。但注意一个边界：协议加密保护的是「第一段」，它替你做的是「不让 GFW 认出你在翻墙」，而「内容不被偷看」这件事，始终由第二段的 HTTPS 负责。两者缺一不可，却常常被混为一谈。

还有一个必须知道的例外：TLS 握手早期的 ClientHello 里，SNI（服务器名称）字段是明文的——它告诉服务器「我要访问哪个域名」，而这段明文正好穿过机场节点。也就是说，即使内容加密，机场仍然知道你在访问哪些网站。GFW 的 SNI 检测利用的正是同一个字段，原理详见GFW 工作原理指南。ECH（加密 ClientHello）可以把 SNI 也藏起来，但它的保护对象是「链路中间人」，对你的机场而言，目标域名本来就会通过代理协议头部告诉它——加密≠匿名，这个区别下一节展开。

六、机场到底能看到你什么？

把「可见/不可见」摊开成一张清单，机场侧的视角就非常清楚了：

维度	机场能看到吗	说明
目标域名/服务器 IP	✅ 能看到	来自代理协议头部与 SNI（无 ECH 时）
连接时间与流量大小	✅ 能看到	什么时候连、连了多久、传了多少字节，形成「行为画像」
你的真实 IP	✅ 能看到	建立连接时必然暴露，日志里最常见的字段
DNS 查询	⚠️ 取决于配置	DNS 泄漏时查询走明文，详见防泄漏指南
HTTPS 网页正文	❌ 看不到	TLS 端到端加密，除非对你做中间人（见下节）
登录密码、Cookie	❌ 看不到	同上，前提是站点用了 HTTPS 且没有中间人
端到端加密 App 内容	❌ 看不到	微信、Telegram 私聊、Signal 等应用层再加密一层

这张表解释了为什么说「加密不等于匿名」：HTTPS 帮你藏住了内容，但「你是什么时间、访问了哪些域名、流量多大」这类元数据，对机场几乎是透明的。元数据能干什么？足够描绘一个人的上网画像：深夜高频访问某个视频站、每天固定时间连某个跨境服务、某个域名突然流量暴涨——这些模式不需要看内容就能推断出来。

理解这层信任边界之后，选机场的逻辑就清晰了：你无法验证一家机场到底有没有记日志，能做的只有把流量交给运营透明、口碑可查的服务商。自建节点把信任收回到自己手里，最干净但最费心；不想维护服务器的人，选择就变成「在可信赖的运营者里挑线路」。全 IEPL 线路的SS-ID这类专线机场，至少线路类型清晰、套餐长期稳定，比打一枪换一个地方的临时服务商更可预期。另外提醒一句：DNS 泄漏会让「你以为加密了」的查询走明文出去，等于把访问记录直接送给旁观者，检测和修复方法见这篇客户端防泄漏指南。

七、中间人攻击：小绿锁是怎样被伪造的

中间人攻击（MITM）的原理一句话就能说清：攻击者插到你和服务器中间，跟你各建一条 TLS 连接——对你假装是服务器，对服务器假装是你。你的流量经过它中转，内容被一览无余。听上去很恐怖，但注意一个关键前提：它必须让你接受一张伪造的证书。你验证的是「证书链完整 + 域名匹配 + CA 可信」，攻击者拿不出目标域名的合法私钥，只能出示自己的证书，浏览器必然报警。所以现代 HTTPS 下的中间人攻击，真正的突破口从来不在密码学，而在下面三个环节：

用户点了「继续访问」：证书警告弹出来，很多人想都不想就点过去。攻击者等的就是这一下；
设备里被植入了恶意根证书：攻击者把自己的 CA 证书装进你的系统信任库，之后它给任何域名签的证书都会被浏览器放行。常见于来路不明的客户端、破解软件、钓鱼安装包；
合规性中间人：企业网关、学校网络、部分政企办公环境会统一安装根证书做流量审计，技术上完全可行，只是做这件事的主体从「攻击者」变成了「网络管理者」。

公共 Wi-Fi 的威胁也属于这一类，但细节和传闻不太一样：在加密的 HTTPS 面前，咖啡店的恶意热点没法直接「解开」你的流量，它更常用的手段是降级攻击——把你导到不带加密的 HTTP 版本网站（HSTS 能防住大部分），或者干脆搭一个长得一模一样的钓鱼页面等你输入。真正危险的场景是「HTTPS 加密 + 恶意客户端」的组合：免费节点或来路不明的机场如果真想偷你的密码，技术路径只有一个——诱导你安装它签发的根证书或专用客户端，在本地做解密。正规机场不会这么做，动静太大、信任瞬间归零；而免费节点的风险恰恰在于你根本不知道运营者是谁，免费 vs 付费的安全差异，这篇免费机场横评有完整拆解。

最后澄清一个常见混淆：Clash、Surge 等客户端自带的「MITM/解密」功能，和攻击者的中间人是两码事。前者是你自己对自己的流量做解密，用来调试规则或抓包，私钥在你手里；后者是别人对你的流量做解密，私钥在对方手里。判断标准很简单：解出来的明文，最终进了谁的眼睛？

八、加密之外：IP、账号与「匿名」的最后边界

HTTPS 保护传输，元数据保护不了，还有一个维度连 TLS 都管不着——你是谁。网站和平台侧看不到你的加密内容，但看得到你的出口 IP，而这个 IP 会泄露大量信息：来自哪个机房、被多少账号共用过、是不是被标记为代理。ChatGPT 拒绝机房 IP、Netflix 按 IP 判断区域、电商平台拿 IP 关联账号，全部建立在「出口 IP = 网络身份证」这个事实上。关于原生 IP、住宅 IP 与各种解锁机制的关系，这篇流媒体解锁与 IP 类型指南讲得最透。

对普通用户，出口 IP 是共享的机场节点 IP，行为特征会被「平均化」，问题不大；但对跨境电商多账号、流媒体重度用户、AI 服务订阅这些场景，机房 IP 的共享历史和风控标记就是实打实的门槛。此时把出口换成住宅 IP/原生 IP，等于告诉对方「我是一个普通家庭宽带用户」。主打住宅 IP 的仙路湾这类机场，卖的本质就是这个「身份伪装层」——它和 HTTPS 是互补关系：HTTPS 保证传输中没人偷看，住宅 IP 保证到达后不被当成可疑对象。把整条链路的安全边界串起来看：传输加密（TLS）→ 元数据（机场可见）→ 出口身份（IP 画像）→ 应用层账号（风控），每一层都有各自的攻防逻辑，指望一把小绿锁包打天下是不现实的。

举一个真实场景：ChatGPT、Claude 这类 AI 服务同时卡两道门槛——登录时看出口 IP 是否来自被标记的机房，使用中看账号行为是否异常。TLS 把「你在和 ChatGPT 通信」这件事藏不住，机场侧看得到域名；而 ChatGPT 侧看得到你的出口 IP 是不是机房段。两道门槛分别对应元数据透明和 IP 画像两个问题，谁都无法用 HTTPS 解决，只能靠线路类型和账号策略去适配，完整解法可以对照这篇ChatGPT Plus 订阅与防封指南。理解到这一层，你对「加密能做什么、不能做什么」的认知就和多数教程作者站在同一高度了。

九、给普通用户的安全自检清单

原理讲完，落到操作。下面这份清单不需要任何安全背景，照着做一遍就能把 HTTPS 链条上最常见的漏洞补上。建议每半年或换新设备时过一遍：

别点证书警告。浏览器弹出「连接不是私密连接」时，唯一正确的动作是离开页面。尤其是银行、邮箱、社交网站——正规站点不会要求用户忽略证书错误来访问。
检查系统信任库。Windows 打开 certmgr.msc →「受信任的根证书颁发机构」，macOS 打开钥匙串访问 →「系统根证书」，手机在设置里找「加密与凭据」。逐个扫一遍，看到不认识、名字可疑、近期凭空出现的 CA，直接删除。企业配发的电脑可能带有公司统一安装的审计根证书，是否接受由你自己判断。
订阅链接必须走 HTTPS。机场面板给的订阅地址如果是 http:// 开头，要警惕——明文订阅在公共网络上可以被替换成恶意节点。把订阅链接粘进浏览器访问一次，确认地址栏有小绿锁再导入客户端。
客户端只从官方渠道下载。Clash Verge Rev、v2rayN、Sing-Box 这类开源客户端，只从 GitHub Releases 或项目官网获取。搜索引擎置顶的「高速下载版」「破解优化版」是植入恶意根证书和挖矿脚本的重灾区，比免费节点危险得多。
防泄漏三件套定期测。DNS 泄漏、WebRTC 泄漏、IPv6 泄漏是三个最常见的「自以为加密」漏洞，泄漏检测网站几分钟就能跑完，发现问题后按客户端文档关掉对应开关即可。
用 CT 日志反查域名。如果你有网站或自建节点域名，去 crt.sh 搜一下自己的域名，看有没有陌生 CA 给它签过证书——那是被恶意签发的信号，也是中间人攻击留下的公开痕迹。
敏感操作分流。网银、税务、政务类操作走直连或可信度最高的线路，不要在免费节点上做；跨境多账号操作使用住宅 IP 出口，避免共享机房 IP 带来的关联风险。
给常访问的站点做「体检」。把域名丢进 SSL Labs 的 SSL Server Test，几分钟能拿到从协议版本、加密套件到证书链的完整评分。评分低说明站点 HTTPS 配置老旧，敏感信息少填为妙。

这份清单的本质，是把「信任」从默认变成显式：每一次点「继续访问」、每一次安装来路不明的证书、每一次使用明文订阅链接，都是在亲手拆掉 HTTPS 的防护。反过来，只要这些环节不出问题，TLS 这套加密体系至今没有过实用化的破解记录——现实中密码被盗，几乎都是信任链上某个环节松了，而不是算法本身出了问题。把本文的框架浓缩成一句话：传输靠 TLS 加密，元数据靠线路商可信度，身份靠出口 IP 类型，账号靠使用习惯——四层各管各的，任何一层单独拎出来都不是「绝对安全」，合在一起才是大多数人能长期用的安全模型。

十、常见误区与 FAQ

Q1：HTTPS 等于绝对安全吗？

不等于。HTTPS 只保证「传输过程中内容不被窃听和篡改」，前提是证书校验没有被绕过。它不保护元数据（域名、时间、流量大小）、不保护你的出口 IP、也不保护你访问的网站本身是否安全。加密是安全链条的一环，不是全部。

Q2：机场能看到我的微信、Telegram 聊天内容吗？

看不到。微信和 Telegram 的「私密聊天」在应用层做了端到端加密，即使流量被完全解密，对方看到的也只是密文。机场最多能看到「你在和微信服务器通信」这个事实。需要区分的是：普通群聊和默认聊天未必端到端加密，真正的秘密通信请用专门的端到端加密工具。

Q3：访问网站弹出「证书错误」，能点继续访问吗？

不能，尤其是陌生网站和公共网络环境下。证书错误 = 浏览器无法验证对方身份，可能原因包括：网站配置错误（较少见）、你的系统时间不对（常见）、网络里有人在做手脚（需要警惕）。正确做法是换网络或换设备再试一次，而不是点「继续」。

Q4：ECH 能彻底隐藏域名吗？

ECH（Encrypted ClientHello）能把 TLS 握手里的 SNI 加密，让链路中间人看不到你访问的域名。但要泼两盆冷水：第一，它主要保护「直连」场景，走机场时目标域名本来就会通过代理协议告诉机场，ECH 对机场无效；第二，ECH 需要网站、DNS、浏览器三方支持，目前覆盖有限，且可能被 GFW 以「不支持的特征」直接阻断。域名隐私的现实答案仍然是不完整的。

Q5：公共 Wi-Fi 上用机场，还需要额外开 VPN 吗？

不需要。机场本身就是加密隧道，公共 Wi-Fi 上的恶意热点看不到你隧道里的内容。真正要防的是两件事：一是在连上公共 Wi-Fi 之前，你的设备可能已经在直连状态下发起了请求（先连热点、后开代理的窗口期）；二是 DNS 泄漏，让查询绕过隧道走明文。把机场设为「按需连接」并在客户端里开启防泄漏，比再加一层 VPN 更有效。

Q6：自建节点是不是一定比机场安全？

在「信任边界」上是的：自建把流量终点收回到自己控制的 VPS，没有第三方记录你的访问日志。但安全是系统工程：VPS 被入侵、面板有漏洞、私钥泄露，风险一点不比机场小，还需要你自己维护。机场模式的安全上限取决于运营者，自建模式的安全上限取决于你自己——对多数人来说，后者更难做到。折中方案是「主力机场 + 敏感操作走自建」的分流架构。

Q7：怎么检查自己有没有被中间人？

最直接的信号是浏览器证书警告。进阶做法：用 openssl s_client 对比证书指纹是否与官方公布一致；检查系统信任库有没有多出陌生的根证书（Windows 的 certmgr、macOS 的钥匙串访问）；留意 HSTS 站点是否出现「证书错误」——被预加载的站点理论上永远不会报证书错，报了就是有鬼。对科学上网用户，额外检查客户端的订阅链接是不是 HTTPS、有没有被替换成陌生节点。

Q8：访问纯 HTTP 网站（没有小锁）时，机场能看到内容吗？

能，而且完全透明。HTTP 是明文协议，机场节点在转发时可以看到完整的请求路径、参数和响应内容。2026 年的主流网站几乎全站 HTTPS，但仍有不少论坛、老站点和部分下载站停留在 HTTP。对这些流量，唯一的保护是「别在 HTTP 页面输入任何敏感信息」，或者换用支持端到端加密的应用层工具。这也是为什么浏览器地址栏的「不安全」标记值得认真对待。

Q9：机场能知道我看了什么视频、下载了什么文件吗？

看得到「域名级」信息：视频站的域名、文件服务域名，以及连接的时长和流量大小——所以它能推断「你在看视频、看了挺久、流量不小」，但看不到具体看了哪个视频、下载的文件内容是什么。内容真正暴露只有两种情况：一是目标网站本身是 HTTP 明文（见 Q8）；二是你主动信任了对方签发的证书（见 Q3、Q7）。把「域名可见」和「内容可见」分开，是理解机场隐私模型的起点。

Q10：为什么开着代理时，有些银行 App 和支付网站反而打不开？

两个常见原因。一是证书锁定（certificate pinning）：银行类应用把服务器证书指纹写死在客户端里，流量经过代理节点时，一旦 TLS 会话特征与预期不符，应用会直接拒绝连接或触发风控。二是风控误判：出口 IP 是共享机房 IP，已被风控系统标记为高风险，银行、支付平台宁可错杀也不放行。解决办法：把银行、政务、税务类域名加进直连规则，或使用住宅 IP 类型的出口。以 Clash 系客户端为例，在规则最前面加几条 DIRECT 就能让网银流量绕开代理：

rules:
  - DOMAIN-SUFFIX,icbc.com.cn,DIRECT
  - DOMAIN-SUFFIX,ccb.com,DIRECT
  - DOMAIN-SUFFIX,paypal.com,DIRECT
  - DOMAIN-KEYWORD,bank,DIRECT

别为了「更安全」硬开全局代理访问银行——你以为多一层加密，实际是多触发一层风控。

Q11：地址栏的小锁变灰、带感叹号是什么意思？

通常是混合内容：页面本身走 HTTPS，但里面嵌了 HTTP 明文加载的图片、脚本或样式。现代浏览器不会因此显示红叉，但会降级提示「不安全」。脚本类混合内容尤其危险——明文脚本可以被中间人替换，等于在加密页面里植入木马。遇到这类提示，尽量别在这个页面输入敏感信息，并可以考虑换用隐私性更好的浏览器或插件强制 HTTPS。