什么时候该关心加密传输
早上上班，咖啡还没喝完，客服就甩来一张截图：用户登录时提示“连接不安全”，要求技术赶紧处理。这类问题其实很常见，尤其是内部系统对外提供服务时，稍不注意就会暴露在明文传输的风险中。
核心问题就是：客户端连接是否加密传输。别小看这一步，它直接决定了用户名、密码甚至操作记录会不会被别人“偷看”。
怎么看连接有没有加密
最简单的办法——看网址栏。如果你用的是浏览器，地址以 https:// 开头，那基本是加密的；如果是 http://，那就是裸奔。
但这只是表象。真正要确认，得看背后的协议。比如你写了个小程序连后台API，用的是HTTP还是HTTPS？如果代码里写的是：
fetch('http://api.example.com/user')那数据就是明文传的，局域网里有人抓包，你的请求内容一眼就能看到。
非浏览器场景怎么办
很多客户端不是浏览器，比如手机App、桌面程序、IoT设备。这时候就得从技术层面查。最常见的方法是抓包。
用 Wireshark 或 Charles 打开，发起一次请求，看看走的是 TCP 还是 TLS。如果能看到原始 JSON 数据，那肯定没加密。如果数据是乱码，但能看到 Client Hello、Server Hello 这类记录，那大概率是 TLS 加密了。
怎么强制启用加密
后端服务可以用 Nginx 做反向代理，直接把 HTTP 重定向到 HTTPS：
server {
listen 80;
server_name app.example.com;
return 301 https://$host$request_uri;
}同时确保后端接口只监听 HTTPS，避免绕过。客户端代码里也别写死 HTTP，配置项统一走安全协议。
自建服务别忽略证书问题
有些公司用内网域名，自己发证书。这时候客户端必须信任这个根证书，否则就算加密了也会报错。Android App 要在 network_security_config.xml 里声明可信 CA，iOS 也得在 plist 配置 ATS 例外。
不然用户打开App，弹个“无法连接服务器”，回头就卸载了，根本不会告诉你是因为证书不受信。
API 接口别留后门
开发阶段为了方便，有些人会留个 HTTP 接口测试用。上线忘了关，就成了突破口。黑客扫描到这个端口，直接拿明文数据走人。
建议所有服务默认关闭非加密端点，通过 CI/CD 流水线控制，部署时自动检查配置文件里有没有 http:// 的监听地址。
加密不只是加个 S 的事，它是从客户端到服务端整个链路的信任链条。少一环，风险就翻倍。