我接手过一个内部项目几十台设备分布在好几个网段管理页面全都跑在http://192.168.x.x上。一开始没人在意协议直到业务方要求网页端直接调摄像头做人脸登记问题立刻暴露——浏览器一律拒绝控制台疯狂刷NotAllowedError换浏览器也一样。后来我索性把整套内网服务迁到 HTTPS并装上了由受信任 CA 签发的域名证书摄像头权限一次通过整个访问链路也顺手变安全了。这篇文章就围绕这件事展开。我会讲清楚为什么 HTTP 内网服务调不动摄像头怎么规划域名与证书怎么申请 LE 这类免费证书以及 Nginx 落地配置和一堆实测踩坑记录。适用场景包括但不限于局域网 Web 管理后台、内网监控系统、树莓派/工控机上的 Web 服务以及任何基于getUserMedia的页面应用。下面内容是我实际搭过、跑通的方案可以直接照着抄。1. 为什么内网Web页面总是调不动摄像头1.1 浏览器不是乱拒绝Secure Context 机制很多人以为浏览器把getUserMedia权限和“用户许可”混为一谈实际上getUserMedia的触发条件里用户授权只是最后一步。在弹出授权框之前浏览器内部还有一道硬性门槛当前页面必须处于“安全上下文Secure Context”中。W3C 和各大浏览器厂商对安全上下文的定义很直接要么页面通过 HTTPS 加载要么地址是http://localhost或http://127.0.0.1这类回环地址。除这两种情况以外哪怕页面本身是内网 IP、内容完全可信浏览器也会认为“这个环境不安全”从而直接禁止调用摄像头和麦克风。我在 Chrome 里做过一次测试用http://192.168.31.10打开页面依次执行navigator.mediaDevices.getUserMedia({ video: true })结果返回的不是用户拒绝而是NotAllowedError: Permission denied浏览器甚至不会弹权限询问框。这就是内网 HTTP 页面调摄像头的本质问题——不是设备权限被占用也不是代码写错而是运行环境不被信任。1.2 localhost 是“例外”这给了我们一个错觉开发调试时一切正常因为浏览器默认把localhost当作安全上下文。http://localhost:8080可以正常调摄像头于是很多同学形成路径依赖写完代码在本机测一遍没问题就丢给部署结果一上内网就翻车。我在本地调试时也踩过这个坑。页面在笔记本上跑得好好的换到平板通过局域网 IP 访问摄像头直接罢工。刚开始怀疑是跨域问题排查了半天才发现是安全上下文不满足。如果只是偶尔调试临时用chrome://flags/#unsafely-treat-insecure-origin-as-secure把内网 IP 加进“不安全来源豁免名单”也能凑合但这既不方便也容易让其他同事误以为可以长期容忍 HTTP方案不可持续。1.3 真正要解决的两层信任HTTPS 与 CA 信任链要让内网设备以 HTTPS 访问并调用摄像头有两个环节必须同时成立第一服务端要启用 HTTPS保证页面从传输层开始就是加密的。这一步解决“安全上下文”问题。第二HTTPS 使用的证书必须让浏览器“认账”。这里有个容易踩的误区很多教程推荐内网自建 SSL 证书自己当 CA 签一张或者用openssl req -x509生成自签名证书。从技术角度这些证书确实能开启 HTTPS但浏览器会弹出“您的连接不是私密连接”的警告页面此时安全上下文依然是 unreachable摄像头照样调用不了。实际上Chrome 把“证书是否被信任”和“页面是否处于安全上下文”是绑定的——只有证书链验证通过页面状态才会变成secure。所以内网 HTTPS 服务器的正解不是“随便签一张”而是安装一张由浏览器内置信任的 CA 机构颁发的域名证书。这里的 CA 可以是公共 CA比如 Lets Encrypt简称 LE也可以是 DigiCert 这类商业证书服务商我习惯简称 DC。这张证书签给一个合法域名再把该域名解析到内网 IP客户端用域名访问证书校验就能通过摄像头自然也能用。2. 整体方案设计服务器、证书与域名怎么搭2.1 服务器软件选型Nginx 作为主力Caddy 作为备选自建 HTTPS 服务器文件服务、反向代理、RTSP 转 Web 这类场景我优先推荐 Nginx。理由有三个配置语法简单、性能稳定、社区资料足够多。给内网摄像头管理页面做 HTTPS 接入Nginx 完全够用而且证书续期后的重载非常方便nginx -s reload就能生效无需中断连接。如果只为了快速跑一个“带 HTTPS 的静态页面服务”我更推荐 Caddy。它最大的特点是能自动从 Lets Encrypt 申请证书并把 HTTPS 配置全自动化很多前期试水的部署半小时就能搞定。但 Caddy 自动申请证书依赖 HTTP-01 或者 DNS-01 验证如果内网没有公网 IP 或可用域名控制权自动化流程反而容易卡壳。我的经验是追求长期可控性用 Nginx追求快速出效果用 Caddy。这篇文章里我以 Nginx 为主线讲解因为它更适合生产环境。2.2 证书来源LE 免费证书与 DC 商业证书怎么选证书来源直接决定了内网客户端是否需要手动“信任根证书”。我整理过一张对比表看过就明白为什么我坚持用公共 CA对比维度Lets EncryptLE商业证书如 DigiCert 等自建 CA / 自签名客户端信任程度浏览器直接信任浏览器直接信任需要手动安装根证书否则报错费用免费有效期 90 天按年收费免费签发验证方式DNS-01 / HTTP-01域名验证、组织验证自己签给自己内网部署友好度高DNS-01 无需公网 80/443高但采购流程重低每台客户端都要配置维护成本自动续期脚本每年手动购买、更新要管理 CA 根证书、吊销列表等Lets EncryptLE是内网服务器性价比最高的选择它的证书虽然只有 90 天但 acme.sh 这类工具可以自动化续期一旦配置好几乎不需要人工介入。商业证书的优点是有效期长、有企业背书但内网项目一般没必要花这笔钱。自建 CA 的坑在主句后半句内网客户端都要导入根证书几十台电脑逐个弄一遍运维成本立马起飞。顺带解释一下标题里的“DC”。如果在企业环境中有自己的证书体系DC 也可能指企业内部 CA 服务Domain Controller 兼 CA但从“解决摄像头权限”这个目标来看开销最小、效果最直接的路径始终是公共 CA 签发的域名证书LE 就是典型代表。2.3 用 DNS-01 验证绕开公网 IP 限制申请 LE 证书需要一个验证域名所有权的步骤常见有 HTTP-01 和 DNS-01 两种方式。HTTP-01 需要在公网 80 端口放一个特征文件CA 服务器会主动来访问验证。内网服务器没有公网 IP 时这一步基本没办法完成。DNS-01 则完全不同它要求你在域名的 DNS 记录里添加一条 TXT 记录CA 通过查询这条记录来验证你对域名的控制权。因为 TXT 记录是公开可查询的即使你的服务器完全在内网、没有公网入站端口也可以正常签发证书。我强烈建议所有内网自建 HTTPS 的项目都使用 DNS-01 验证。以我常用的 acme.sh 为例只要域名托管在阿里云、腾讯云、Cloudflare 等平台配置好 API 密钥脚本会自动添加和删除 TXT 记录全程无需人工干预证书签发成功率接近百分之百。2.4 内网域名规划一个二级域名对应一台设备证书是签给域名的不是签给 IP 的。如果访问地址是https://192.168.1.100即使证书完全合法浏览器也会因为“域名不匹配”报错。所以内网 HTTPS 必须引入域名规划。最省事的办法是给每台设备分配一个二级域名例如设备内网 IP访问域名摄像头管理服务器192.168.1.10cam.example.com门禁设备192.168.1.11door.example.comNAS 或文件服务192.168.1.12nas.example.com然后把每个二级域名解析到对应的内网 IP。这个解析既可以放在公网权威 DNS 上A 记录写 192.168.x.x也可以放在内网自建 DNS 上。只要签发证书用的是同一个域名客户端访问的也是同一个域名证书就能正常校验。我遇到过的其中一个反面案例是同事把“证书域名不匹配”误当成了“证书损坏”结论其实是访问 IP 导致的。所以一开始就规划好域名映射能省掉后面大量排查时间。3. 实操落地申请证书并部署 HTTPS 服务器的完整流程3.1 准备工作域名管理、DNS解析与服务器环境开始之前先把下面三件事确认好第一你手头有一个域名并且能登录域名托管商的控制台。我用的是阿里云下面以阿里云 DNS 为例。第二把要用的二级域名比如cam.example.com解析到内网 IP。A 记录填 192.168.1.10TTL 默认即可。这么做也是一个双保险即使内网 DNS 没配好客户端通过公网 DNS 也能查到 IP不要担心公网可查内网地址是否有安全风险因为最终地址是私有网段外部网络无法直接路由。第三服务器上装好 Nginx 和 acme.sh。我建议用 Debian/Ubuntu 系列系统安装命令最直观apt update apt install -y nginx cron socat curl https://get.acme.sh | sh -e emailyourexample.com装完之后Nginx 默认站点先不用管acme.sh 的安装目录会在当前用户主目录下后续命令都要用完整路径调用。3.2 使用 acme.sh 申请证书并配置自动续期申请证书前先给 acme.sh 配置 DNS 服务商的 API 密钥。以阿里云为例需要在 RAM 子账号里创建一个具备AliyunDNSFullAccess权限的 AccessKey然后导出环境变量export Ali_Key你的AccessKey ID export Ali_Secret你的AccessKey Secret接着执行签发命令~/.acme.sh/acme.sh --issue --dns dns_ali -d cam.example.com我解释一下这条命令背后的逻辑--dns dns_ali是告诉 acme.sh 使用阿里云 DNS 的 API 去添加 TXT 记录--issue是发起签发-d指定证书域名。脚本运行时会自动完成“生成密钥对 → 请求 LE 签发 → 添加 TXT 验证记录 → 等待生效 → 下载证书”整个流程。第一次执行可能需要一两分钟看到Cert success就表示证书已经躺在~/.acme.sh/cam.example.com/目录下了。证书签发后还不能直接用。acme.sh 的证书文件放在它自己的管理目录中建议安装到 Nginx 的标准目录同时自动注册续期钩子~/.acme.sh/acme.sh --install-cert -d cam.example.com \ --key-file /etc/nginx/ssl/cam.example.com.key \ --fullchain-file /etc/nginx/ssl/cam.example.com.pem \ --reloadcmd systemctl reload nginx这样操作之后证书密钥会复制到/etc/nginx/ssl/下每次续期成功后还会自动重载 Nginx不用手工干预。3.3 Nginx 站点配置与证书安装先创建证书目录mkdir -p /etc/nginx/ssl然后写一个独立的 server 配置。下面是我实测可用的基础配置里面我把 HTTP 强制跳转到 HTTPSserver { listen 80; server_name cam.example.com; return 301 https://$host$request_uri; } server { listen 443 ssl http2; server_name cam.example.com; ssl_certificate /etc/nginx/ssl/cam.example.com.pem; ssl_certificate_key /etc/nginx/ssl/cam.example.com.key; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5; root /var/www/cam; index index.html; location / { try_files $uri $uri/ 404; } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Forwarded-Proto $scheme; } }这里有几个关键点值得展开证书文件我统一用fullchain.pem它包含站点证书和中间证书省去手动拼接 CA 链的步骤。如果你只配置站点证书而漏掉中间证书移动端 Chrome 和 Safari 会报ERR_CERT_INCOMPLETE_CHAIN。ssl_ciphers HIGH:!aNULL:!MD5是兼容性与安全性的平衡如果用 TSL 1.2 的老设备访问有问题可以再加一行ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384。/api/反向代理到内网后端应用这一步针对摄像头页面通常很需要因为后端接口也要和页面同源。配置完成后执行nginx -t systemctl reload nginx浏览器访问https://cam.example.com如果地址栏出现锁型图标说明证书链路已经通了。3.4 浏览器信任验证与摄像头授权全流程测试证书配好后验证手段很简单。按 F12 打开开发者工具切到 Console直接输入navigator.mediaDevices.getUserMedia({ video: true, audio: false })如果返回了一个Promise并弹出摄像头授权询问框说明Secure Context已经满足。点允许之后页面就能正常拿到视频流。我在实测中总结过一个稳定的判断顺序验证步骤预期结果如果不满足怎么办地址栏协议https://cam.example.com检查 Nginx 是否监听了 443锁图标无警告字样查看证书是否过期或域名是否匹配window.isSecureContexttrue说明证书信任链还有问题getUserMedia弹出授权框往控制台看具体错误码window.isSecureContext是一个非常有用的诊断字段。它可以直接告诉你当前页面是否处于安全上下文比肉眼判断报错更精确。我排查过不少案例很多人明明用了 HTTPS 但页面仍然显示不安全一查isSecureContext是false再往下翻发现是证书用的 IP 直连而不是域名访问。另外getUserMedia在授权后返回的是MediaStream对象。页面上一般会用video标签把它渲染出来navigator.mediaDevices.getUserMedia({ video: true }) .then(stream { const video document.getElementById(localVideo); video.srcObject stream; }) .catch(err console.error(err.name, err.message));正常情况下授权后画面会直接在页面上显示。如果授权后黑屏只可能是设备被占用或者视频标签未设置playsinline属性iOS 上常见。4. 常见问题排查与避坑记录4.1 证书报错 NET::ERR_CERT_AUTHORITY_INVALID这是内网 HTTPS 最常撞见的错误。原因基本都是证书不是由受信任 CA 签发或者证书链不完整。我曾经为了省事直接在一台工控机上用openssl req -x509生成了十年有效的自签名证书然后所有设备打开页面都弹红色警告。当时我想当然地认为“点继续访问就行”结果测试浏览器权限弹窗始终不出现。原因就是 Chrome 在安全上下文评估时对证书信任的判断非常严格自签名证书会导致isSecureContext为false。如果已经用 LE 签发了证书但仍报这个错误优先检查Nginx 配置的ssl_certificate使用的是不是fullchain.pem系统时间是否准确证书校验依赖客户端和服务端时间访问域名和证书域名是否完全一致包括www前缀4.2 摄像头权限弹窗始终不出现的排查思路页面已经通过 HTTPS 访问证书也完全受信任但getUserMedia依然不弹授权框这种情况多半是两种原因第一种是“权限策略”干扰。HTTPS 页面可以在响应头里指定Permissions-Policy如果 Nginx 或其他代理层配置了Permissions-Policy: camera()摄像头权限会被服务端策略直接禁用。检查一下响应头curl -I https://cam.example.com看到Permissions-Policy里没有camera关键字才算正常。第二种是“非安全上下文残留”。如果在之前的历史页面里访问过 HTTP 版本浏览器可能缓存了一个不安全的标记。我遇到过一次清理站点数据后恢复正常。建议排查时顺手清掉该域名的全部缓存再做测试。另外企业内网电脑如果装了统一上网行为管理或 DLP 客户端也可能拦截摄像头设备。这类问题无法通过修改服务器解决只能靠客户端侧排查。我建议先用手机浏览器连同一网段测试如果手机正常、电脑异常说明问题基本出在电脑侧。4.3 HTTP 跳转 HTTPS 后资源被拦截把站点强制跳转到 HTTPS 后页面里用 HTTP 协议引用的图片、接口、JS 资源都会被浏览器拦截表现为功能脚本没加载、页面样式丢失。Chrome 会提示Mixed Content。我建议在 Nginx 加入一个通用的“内容安全策略”响应头强制所有资源走 HTTPSadd_header Content-Security-Policy upgrade-insecure-requests always;这个头的作用是让浏览器自动把页面里的http://资源替换为https://请求老项目迁移时特别管用。不过它只对相对路径或同域资源有效如果 JS 代码里硬编码了http://192.168.x.x的接口地址还是要手动去代码里改成https://域名才能彻底根治。4.4 其他容易被忽略的“权限”类问题顺着标题里的“权限”再延伸说两句。内网部署 Web 服务时除了浏览器侧的摄像头权限“系统文件权限”和“注册表权限”也经常让新手抓狂。我在给服务器配置证书目录时遇到过setnamedsecurityinfo failed (win32)这类 Windows 上报错本质是 Nginx 服务账户没有权限读取证书私钥文件。Linux 上对应的问题是 nginx 运行账户通常www-data无法访问根目录下的私钥。解决思路很简单确保/etc/nginx/ssl/目录对所有者为 root、组为www-data权限设为 640chown root:www-data /etc/nginx/ssl/cam.example.com.key chmod 640 /etc/nginx/ssl/cam.example.com.key如果你在 Windows 上做内网部署注册表权限报“你需要来自 administrators 的权限才能更改”原则也一样——不要强行去夺取所有权先检查服务是否以管理员身份运行。很多“权限删不掉”“权限改不了”的问题背后都是操作者试图绕过合规路径而不是系统故意刁难。这个道理放在摄像头权限、文件权限上都通用让服务运行在最小化权限但具备访问资格的账户下比直接给管理员权限更省心。另外热词里提到的bluetooth le spam这类内容和本文项目没有直接关系但如果你未来要开发 Web Bluetooth 的功能同样要遵守 HTTPS 和域名证书的规则原理一致。4.5 局域网 DNS 解析与浏览器预加载 HSTS 的坑最后分享一个容易被忽略的小坑。如果你把域名解析到了内网 IP但客户端的 DNS 服务器查询速度很慢页面首次打开会卡顿几秒。更麻烦的是如果某个域名曾经的证书过期浏览器 HSTS 列表里可能记住了“强制 HTTPS”的状态之后你改成 HTTP 测试反而打不开。内网环境里我建议直接在客户端 hosts 文件里静态映射域名和 IP192.168.1.10 cam.example.com这样既能快速访问又不会受 DNS 缓存或 HSTS 影响。当然如果内网设备众多用自建 DNS 统一管理更好但 hosts 方案在个别设备上排错更直接。再补充一点续期后的 LE 证书偶尔会出现“部分设备仍然报证书过期”的错觉这通常不是证书真的过期而是客户端缓存了旧的证书状态。重启浏览器或清除 SSL 状态缓存即可解决。我自己把整套方案跑起来之后又把同样的模式复制给了公司另一个团队他们用来做内网考勤机的人脸识别页面一次通过没有额外配置任何客户端。要说这套方案最大的价值未必是证书本身而是它把两个看似割裂的问题——传输安全和设备权限——用同一个标准统一解决了。以后你再碰到“网页调不了摄像头”的内网项目别再急着调代码先想想你的页面是不是跑在https://域名下。很多时候问题并不在代码里而在浏览器对你服务身份的认可上。