.ovpn 文件究竟包含什么，又不能做什么

大多数人以为 .ovpn 文件能配置 VPN。其实不能：它配置的是一个客户端，而它要求的一切都必须在另一端已经存在。改动文件中的一行，只能改变你的机器尝试什么，永远改变不了服务器提供什么。正是这一区别解释了围绕导入失败或连接不上的配置文件的绝大多数困惑。

把这份文件读成一份发给客户端的请求清单，其中大多数行就变得一目了然。

文件描述的是你的客户端，而不是服务器

一个配置文件会把 remote 端点、传输方式、接口类型、身份材料，以及运营方希望的任何客户端侧行为打包在一起。每一行都由客户端在启动时执行。它们都不会作为配置变更抵达服务器，也没有一行能凭空创建一个本就不在运行的监听器。 一个指向仅监听 UDP 1194 的服务器、却声明 TCP 443 的配置文件 会在第一个数据包上就失败。

这也是同一份文件在两个客户端上表现不同的原因：文件提出请求，客户端决定能满足多少。

传输相关的行必须与已经存在的监听器相匹配

proto和remote两行必须与服务器实际绑定的内容一致。UDP 是常见选择，因为丢失的数据报不会卡住隧道；而 TCP 能穿过限制严格的网络，代价是隧道内部的队头阻塞。把配置文件从 UDP 改成 TCP 并不会让服务器接受 TCP；它只会让客户端发往一个没人读取的端口。

443 端口之所以流行，是因为它能穿过几乎不允许其他流量的网络，而且它仍然是一个 OpenVPN 会话，而不是 HTTPS 请求。如果运营方发布了多条 remote 行，客户端会按顺序尝试，这是一份故障转移清单，而不是负载均衡决策。请保留运营方给出的组合，不要把一条记录里的主机和另一条记录里的端口拼在一起。

内嵌密钥会改变你处理文件的方式

证书和密钥可以内嵌在 <ca>、<cert>和<key>标签之间，也可以通过单独的文件引用。内嵌材料让配置文件自给自足，同时也让它成为一个秘密，因为客户端的私钥就在其中传输。CA 证书是公开的信任材料，可以安全分享；私钥则不行，即使它看起来只是一段读不懂的文字。

保护密钥的口令与账户密码是两回事，把两者搞混会产生一次看起来像凭据错误的认证失败。

路由和 DNS 可能根本不来自这份文件

路由可以由服务器推送，可以由配置文件用 redirect-gateway 设置，也可以留给客户端自己的默认值。因此，你下载的文件并不能完全决定隧道建立后流量走向哪里。当内部名称能解析、公共站点却解析不了时，是分离隧道的策略在按设计工作，而不是出了故障。

DNS 也是同样的模式：被推送的 dhcp-option DNS 可能被客户端应用、被忽略，或被本地解析器管理器覆盖。连接之后请检查解析器的状态，而不是再读一遍配置文件。

不受支持的选项是客户端版本的问题

导入时的警告通常意味着客户端没有实现某条指令，而不是文件损坏。桌面客户端可以在有文档说明的管控下运行脚本和插件，而移动客户端接受的范围更窄，可能会悄悄丢弃看不懂的行。旧客户端拒绝的加密或 TLS 设置属于版本问题，应与运营方一起解决。为了强行导入而启用不熟悉的权限，是用一条警告换来了更大的攻击面。

保留原始文件以便对照，在请求中写明那条不受支持的指令，并向运营方索取为你实际使用的客户端构建的配置文件。

任何替换之后，都要确认应用正在使用哪一条配置文件条目，因为导入新文件并不总会覆盖旧的那一条。