不是这样的，你的理解从一开始就不对。NAT工作在四层上，而你说的是proxy，工作在七层上。NAT只负责在遇到符合规则的数据包时，将源地址或/和目标地址按照映射关系做替换，从而使两个本来不能直接互通的IP地址实现互通。七层协议是不关心底下的四层协议实现细节的，自然不会受影响。
在NAT网络中，建立连接的仍然是客户端和服务器，并没有中间设备和两端建立TCP连接，而是将包括SYN,ACK和FIN在内的所有TCP包都做了地址转换。
另外，HTTP Proxy其实也有透明代理HTTPS的模式，原理是通过CONNECT方法建立一个模拟的TCP连接，然后就可以通过这个模拟的TCP连接进行HTTPS请求了
之所以产生这个理解偏差，可能是因为不熟悉端口映射（PAT）工作原理而造成的。
为了更好地理解PAT的工作原理，先问自己几个问题：
Q1: 为何事先在NAT设备做端口映射？
Q2: 为何不把公网IP直接配置在https服务器上，而是把公网IP配置在NAT设备上？
Q3: 端口映射（PAT）工作在哪层？
Q4：客户端的TCP连接终结（Termination）在哪里？
以下是问题的回答
A1: 只有公网IP才可以在互联网上被用户访问，而服务器的私有IP无法被互联网用户访问，假设公司的公网IP = 1.1.1.1，服务器IP = 10.0.0.1，端口映射将产生以下静态表项：
NAT设备一旦接收目的IP + 端口号为1.1.1.1:443的报文，就会转换为10.0.0.1:443，并将转换好的IP报文继续转发给服务器。
A2：如果把公网IP直接配置在https服务器上，那么公网IP就被https服务器独占了，工作在别的端口号的服务器，如21、80、445端口就无法被互联网用户访问。
而在NAT设备上做21、80、443、445端口映射，可以将这些端口分别映射到特定的服务器上。
A3：端口映射工作在三四层，三层为IP，四层为TCP/UDP。
A4: 如下图所示，客户端的TCP连接被https服务器终结，而不是NAT设备，NAT设备只是做三四层地址+端口号的转换，仅此而已。
如上图，在NAT设备眼里，TLS及应用层的http仅仅是货物，NAT设备对这些货物并不关心是什么，更不会尝试去理解或修改。
同理，客户端的TLS安全会话也是终结在https服务器上，所以和安全有关的话题，如安全加密组件协商、数字证书认证、服务器的私钥签名、RSA交换密钥算法、DH交换密钥算法等等，都是在客户端与服务器之间进行的，无需NAT设备的参与，所以NAT设备无需任何TLS安全有关的配置，仅仅做好自己本职工作即可。
更多详细内容，请关注：车小胖谈网络
https://mp.weixin.qq.com/s/VAU4sFglpsJ8RYZPmrWeaw
我感觉你是将端口映射设备理解成了MITM攻击里的中间人了。
端口映射设备并不是中间人！！！
在对https的MITM攻击里，中间人不仅仅做了数据的转发工作，还做了认证证书的替换；而端口映射设备也做了数据的转发工作，但并没有做认证证书的替换。
举个例子：
假设Alice要访问https://bob.com，正常情况下连接应该如下：
[Alice]<------ 可信CA签发的bob.com证书 ----->[bob.com的服务器]但来了一个中间人Evil，Evil会伪造（一般是自签名）一个http://bob.com证书，发动MITM攻击之后连接变成了这个样子：
[Alice] <--Evil伪造的bob.com证书--> [Evil] <--可信CA签发的bob.com证书--> [bob.com的服务器]Evil会解密Alice意图发给http://bob.com的数据，看看有没有什么机密信息、记录下来，然后再把数据转发给真正的http://bob.com服务器。现实世界中，Alice在接收到Evil伪造的http://bob.com证书时，会发现这个证书不是可信CA签发的，因而会收到浏览器的警报。
但是有端口映射设备的情况下，连接是怎样的呢？
[Alice] <--可信CA签发的bob.com证书--> [端口映射设备] <--可信CA签发的bob.com证书--> [bob.com的服务器]可以看到Alice收到是可信CA签发的http://bob.com证书。为什么？因为这个证书信息是在https握手ip包的payload里，并不在NAT要修改的ip头里，Alice收到是毫无改动的payload，自然也就是未修改的可信CA签发的http://bob.com证书，这https连接凭什么不可以建立起来呢？
你是不是对“穿越”这个词有什么误解？
为什么会有NAT穿越呢？
有些协议的净负载中包含IP地址（SIP），或者与IP地址硬相关（IPSEC，净负载中有IP地址的校验信息）
NAT修改了外层的IP地址和端口后，会导致外层的IP地址与内层净负载中的IP地址（或者硬相关的信息）不一致
导致协议出错
这时候才会考虑NAT穿越，规避这种“不一致”，使协议能正常运行
HTTPS内层有IP地址（或者IP地址的硬相干信息）吗？似乎没有。除非证书颁发给了IP地址
TCP是没错，NAPT确实是工作在这里，但是NAT对TLS完全是透明的，证书和密钥是直接在两端之间传输的。