感觉是光猫软件 Bug ，之前遇上过 ASUS 路由器里面的 "启用 VPN + DHCP 连接" 如果开启就会导致烽火 HG6145D1 吊死的问题。
建议尝试联系联通换其他品牌光猫试试。

下发配置不光得支持 TR069 协议，不同地区的管理 VLAN ，管理接入方式（ DHCP 还是 PPPoE ），管理服务器地址之类的都不一样，即使一样的话有些管理服务器是通过猫型号下发数据，因此猫型号在数据库没有也有可能下发失败。
如果买运营商定制设备的话相对坑会少一些，不过那好像就相当于运营商的猫了。

@baobao1270 七类线有这个问题，超六类即 Cat.6a 是有非屏蔽线的。

另外网线这种要求高的还真是自己买好一点，装修队很多其实不太懂弱电的。

流量几百兆，没有复杂的配置比如需要收 BGP 表之类的，或者国产防火墙对 IPv6 有很多细节分发的需求可以用防火墙充当路由器。不过选型的时候需要选高配置型号且仔细和厂家核实性能指标，因为防火墙做的越多能支持的流量就越低，如果要开 IPS/防病毒/VPN 之类的功能更是如此。同样一台防火墙三层性能和七层性能几乎是跳水级别的，

@datocp 纯 IPv4 + 内网全部过 NAT 的场景可以不上防火墙，因为长期对外暴露的端口一定是主动映射的端口。打洞之类的场景一般出口防火墙也控制不了，毕竟一般出口防火墙策略都是出站允许 any-any 而 NAT 打洞请求是客户机主动发出的，而且打洞需要客户机应用主动发起所以一般敏感端口也不会通过打洞出去。

1. 大多数系统除了 I/O 就是 DB 有瓶颈，因此尽量减轻 DB 负载是必要的。
2. 存储过程的开发维护成本远高于代码，所以能代码解决的肯定不做存储过程。祖传代码已经很难懂了，如果祖传代码套着祖传存储过程怕是以后这个点要变更得先开发和 DBA 结对编程梳理出来逻辑完了再开技术团队会议确定逻辑是否正确以及针对新需求的修改方案吧。

@ho121 小公司不优先使用 3 个内网段和 100.64.0.0/10 不能理解，而且即使需要偷地址也是先偷美国国防部那几个根本不用的大段，随便 YY 地址确实不合理。

另外写死必须是三个内网段才能正常使用的系统确实设计有严重问题。

@iBugOne 是的，现在这种出了问题报告里面可以直接写 "考虑到信息安全因素因此业务部门修改生产数据需进行审批，审批流程较长且缺乏紧急事件的应急响应机制导致业务恢复时间较长" ，到时候开个后门这些话没准就得留到法制节目上说了。
本来计算机相关的罪名入罪条件就极其宽松，恨不得在重要系统或者用户量极大的系统上写个 Bug 都能擦上边，开个后门恐怕只会加速计算机从入门到阶下囚的进程。

@XXOO133 第二点的工信部文件来源请求下，下次有人问我合法性问题我就把文件转给他。

@feitxue 是的，主要是能不能拿到一折两折。价格过高对于大多数用户还不如家宽去想办法搞上行包和公网 IP 包，除非准备备案做网站那种。

应该只要是北京联通宽带（不是沃长宽之类的收编特殊业务）打 10010 就能给，上个月我朋友装了一条异地融合 300M 60 元/月 就是直接跟上门安装外线师傅说了一声就给改了。

测试一下用手机或者其他人的宽带能不能访问，如果从互联网可以访问那可能是 TP 路由器的 NAT 回流有问题。

光猫的接头是 SC-UPC ，不过即使用了 LC 也可以通过跳纤转换为 SC ，但都要是 UPC 的接头因为 UPC 和 APC 之间对接有损耗。
如果没记错的话预埋式的要好点，因为对光纤端面质量要求没有直通式严格。

@bclerdx 这种事儿哪儿说的清楚啊，电磁辐射对人的影响是没有证据证明有害而不是已知无害，再说了一般搞这种的人也别指望有什么科学素养。
热点地区以公共建筑，商业楼宇为主，附近居民数量很少所以形不成规模。
另外小区里边建设基站占用的公共资源是属于业主公有的区域（公共建筑，商业楼宇肯定不属于普通住户），又没有法律法规或者文件规定小区里的基站属于基础设施任何人不得干扰正常运行不得拆除，所以如果支持者超过一定人数那从法理上确实可以拆。

@bclerdx 这种拆基站的投诉一般不是普通的投诉，请参考前几年四家联合声明那几个小区的折腾方法。

光猫本身差异倒是不大，主流厂商都做了互联互通处理，但主要有以下几个问题比较麻烦：

1. 运营商采购的定制光猫通过 TR069 实现了和自家管理平台的对接，如果不支持 TR069 的话就需要手动配置业务数据，就跟当年 ADSL 时代要配置 VPI/VCI 一样但操作起来比 VPI/VCI 复杂不少（毕竟不是纯宽带桥接，有些地方 ONT 入网还需要后台许可才能通）。手动配置的话对维护人员技术要求高不少，而且效率也低（扫码开通十分钟开一台，手动配置半个小时不见得能通）。而且有时候割接之类的还会导致配置变更，如果没有 TR069 下发配置的话那全部得维护人员上门变更，这个工作压力可想而知。
2. 如果通过固件实现集成倒是没问题，但运营商也没法保证适配所有品牌所有型号，而且不同类型光猫支持的能力也不一样，买起来就很麻烦了。比如用户办了条 500M 宽带并赠送一个固话号码，运营商线路是 EPON 的，用户买了个 GPON 只有一个百兆口的杂牌设备，恰巧杂牌设备没适配该运营商该省，这业务怎么开。如果锁定特定的一批型号的话，好像还不如外线直接拿来让客户购买、租用甚至白送呢。
3. 换光猫的理由类似于 1 所提到的现场人员受限于水平排查故障效率很低，复杂的故障协调后台层层排查反倒浪费时间，不如直接换个新的或者良品光猫（这个分地方和库存）解决。坏的光猫拿回去运营商统一找人清零测试，数据问题清零之后测试完直接做备件，硬件故障的在保修期内就返给厂商维修之后测试完再做备件（也有地方不管什么问题统一返给厂商维修的），不在保修期的就报废处理更简单有效率。

1. 撤销低效能 4G 高频站，同频率让给 5G 实现替代。毕竟语音、短信和 IoT 设备对网速需求不高。
2. 可能因为用户投诉、站址不再续租等原因撤销整个站址，那就是 245G 全没了。

断的话记下具体位置和他们反馈让他们解决呗。

缺人砍维护资源这种事情对于任何项目都没办法，而且受影响的范围相对没那么大。
个人用户刨除（内核版本无所谓），中间件适配能力强的用户刨除（比如 Web 类应用或者容器化的应用没那么挑内核），红帽这种具备强大 backport 能力的刨除（团队有能力识别并针对老内核做安全更新），不更新的用户刨除（这年头国内还有一堆 CentOS 6/7 在跑着甚至没有替换计划），剩下的才是影响范围。

@8355 是这样，20 QPS 感觉如果几个人一起用的话确实有可能能顶到峰值，例如 DNS 都指向外网而不是软路由的同时几个人输入域名一起回车的场景。
现在运营商 DNS 搞针对境内网站的 DNS 劫持之类的没有之前那么多了，所以没有 DNS 劫持的地区确实优先考虑运营商 DNS 。

一般这种要求给钱但给不出任何细节的基本都是诈骗。
Bug bounty 可以搞，但一般规则都是先交漏洞后给钱，给多少钱以厂商计算为准。