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 签发客户端证书也是你可控的，这不就好了，虽然这个行为也是可配置调整的，既然你都调整配置了，那你也完全可以指定继续校验客户端证书的其他信息啊，比如指定特定指纹才是有效的

@Greendays #39 为了在游戏里作弊不能，但是为了在游戏里帮别人作弊赚钱可以，23333

@linxuan716 #12 还好吧，阿里云之类镜像服务都有自动化服务吧，授权仓库绑定建 tab 就自定 build ，镜像仓库在设置好触发器自动触发 k8s 更新滚动重启，这不比你拉代码重启还简单

主要问题是业务量不够上了 k8s 会贵不少，维护哪复杂了，更简单了吧

@happydezhangning 显然不能，三个三峡而已，对我国现在的用电量来说也就几分之一，影响电价显然完全没可能，如果把太阳能板铺满罗布泊那发电量那倒是可能了，想达到影响电价年发电量怎么也得有个 3 万亿度还差不多，这可是十几个三峡才能提供的年发电量啊

@rocmax 就这？！！看来你对我国的产能还是认识不足啊

这效果，非常可以了

支持独立开发