@crc8 #6 意思是你的 wan 口应该是获取到 pd 前缀了，可以截图看看，能否下发看你设置了啊，lan 口的中继和混合模式下发的都是主接口的 pd 委托，所以你需要在获取到 pd 的 wan 口来设置为主接口，同时 wan 还要开启下发委托之类的选项吧

我设置成功的，不过我这边似乎获取到的 pd 正常，但是运营上路径的路由表似乎过段时间就失效了，ping 不通，所以我现在还是使用 nat6 了

/64 那个就是 pd 的前缀吧，lan 口咋设置的，没下发？

@kemf #2 直接被掐不就是阿里云腾讯云发现你没正确备案防火墙给你掐了呗，域名备案了但是阿里云还是跳转备案页，那是你没在阿里云上做域名备案吧，域名备案是绑定着云服务商或机房的，更换需要程序在对应的云服务商备案

v6 开启 nat 支持配置端口转发也只能转发到 v6 内网地址吧

不需要这么费劲吧，常用的库比如 okhttp 都支持设置自定义证书验证回调吧，在回调里处理下直接忽略证书过期然后改成直接验证服务器证书指纹就好了啊，也是安全的

import okhttp3.*;
import javax.net.ssl.*;
import java.security.cert.X509Certificate;

public class CustomVerifyOkHttp {

public static OkHttpClient buildClient() throws Exception {
TrustManager[] trustManagers = new TrustManager[]{
new X509TrustManager() {
@Override
public void checkClientTrusted(X509Certificate[] chain, String authType) {
// 不处理客户端
}

@Override
public void checkServerTrusted(X509Certificate[] chain, String authType)
throws CertificateException {
// 示例：只信任特定公钥指纹
X509Certificate cert = chain[0];
String sha256 = sha256(cert.getPublicKey().getEncoded());
if (!"your_expected_sha256_fingerprint".equalsIgnoreCase(sha256)) {
throw new CertificateException("Untrusted server certificate");
}
}

@Override
public X509Certificate[] getAcceptedIssuers() {
return new X509Certificate[0];
}
}
};

SSLContext sslContext = SSLContext.getInstance("TLS");
sslContext.init(null, trustManagers, new java.security.SecureRandom());

return new OkHttpClient.Builder()
.sslSocketFactory(sslContext.getSocketFactory(), (X509TrustManager) trustManagers[0])
.hostnameVerifier((hostname, session) -> true) // 可选：略过主机名验证
.build();
}

private static String sha256(byte[] data) throws Exception {
java.security.MessageDigest md = java.security.MessageDigest.getInstance("SHA-256");
byte[] digest = md.digest(data);
StringBuilder sb = new StringBuilder();
for (byte b : digest) sb.append(String.format("%02x", b));
return sb.toString();
}
}


基本就是这样，这样之后楼上说的什么中间人抓包也没可能了

国产化系统基本上内核、标准库、编译器都很老了，这些货一个一个都完全没计划考虑定期升级个内核什么的，真是坑死个人的

@magic3584 #15 C++代码也是架构和系统绑定的啊，首先动态链接库 windows 叫 dll ，国产底层都是 linux 叫 so ，就算你有源码都不一定能在过程系统上编译出 so 来，这还有工具链、编译器版本和标准库依赖的问题，没源码的话就歇了吧

C#代码就算迁移到.net core 如果不是 asp.net 那一套估计工作量感觉还行，否则几乎等同于重写了吧

不搞个生成二维码

@dorothyREN #1 而且遇到不存在的配置文件查询也立即返回文件已修改，这似乎也不合理吧

@dorothyREN #1 这东西也没啥权限可以设置，用不用的感觉也没啥区别吧，如果只是小团队用估计也没啥必要还去分啥 namespace 吧，但是有这问题就不合理了

我们用的是 proxifier ，proxifier 配规则拦截掉全部对 pod 的 ip 访问，然后在 k8s 里用 deployment 部署一个简单的 socks5 代理来负责转发，安装配置简单，开发过程也是无感的

顺便说如果你用的是大家用挺多的 redis 分布式锁，因为 redis 协议原因，冲突率较高情况下性能会有较大下降，单个加锁延时在冲突率高情况下提高不少，也是需要考虑的
一般来说各种介绍分布式锁使用的文章说到的场景实际冲突率都低于百分之一吧，可以统计或者预估下冲突率在啥价格
如果冲突率实在高又并发不均衡就是有较大峰值，那还是好好的用 kafka 来搞吧

看了半天似乎你这个不就是某个人开始结束时间更新不应该因为时序和并发问题覆盖回跳吧，不用那么纠结按人加锁就是了吧，我看你补充说可能操作的时候不上报结束统一上报，但也就是几百个而已
加锁要分析的是冲突率、单操作耗时和等待时长，然后以此计算线程连接各种资源是否能满足需要的并发，不是加锁就不能高并发吧
就你这也就计算更新个时间耗时这么低，按人加锁也没多大影响吧

你这第一条客户端校验服务端证书就理解不对吧，证书校验就是验证 ca 是否合法，只不过一般的 https 客户端默认使用一堆系统内置的可信 ca 来校验，任意通过即可，所以外加域名验证来确认服务器签发的证书是有效，但是客户端这个行为也是可配置的，如果你指定只信任特定 ca ，而这个 ca 签发服务器证书是有你控制的那就没必要校验域名了啊
而服务器这边开启客户端校验的时候默认行为就是需要添加需要信任的指定 ca 的吧，而且这个 ca 签发客户端证书也是你可控的，这不就好了，虽然这个行为也是可配置调整的，既然你都调整配置了，那你也完全可以指定继续校验客户端证书的其他信息啊，比如指定特定指纹才是有效的