yuguanching

> 有的 關於acceptProxyProtocol 官方文件裡面很多地方都有提到 我最早看到是在webSocket那邊 但無論是出現在哪裡 它的說明都有提到一點： “僅適用於inbound” 也就是說 它只能滿足於「接收」客端IP 這一點也確實有效 我的vless+ws+tls 在inbound的log都有看到客端ip 但涉及到outbound要把流量送出去的時候 則找不到門路 我也有頭鐵直接把acceptProxyProtocol直接在outbound設定 但沒有作用

> 不知道能不能让你明白，或许个别是有误的。 大部分科学上网都是拿节点的ip对解密后流量作类似NAT的地址翻译去转发流量，请求目标网站的从而绕过审查，不可能将客户端的IP直接透传到目标网络。根据路由协议的概念，只有路由转发才能直接将客户端的IP送达，而这个又会受防火墙所监控。或双端的程序做特殊配置（码代码）才能透传客户端真实IP，例如nginx/caddy之类或支持proxy protocol（HAProxy）的反代服务。 > > 就像家里的宽带一样，假定你内网地址是192.168.1.1，以下简称为a。出口网口（宽带拨号后）的地址是172.16.25.25，以下简称为b。目标地址是10.0.35.35，以下简称为c。 当a访问c时，c一般情况下获取到的客户端地址是b（NAT网关）。 但当b和c同时做了特殊配置（haproxy），就能把a的地址正确地传给c。 感謝大大講解 對於科學上網的初衷我能理解 一般來說應是要隱藏客端的ip才能達到保護效果 今天是想透過Xray的優秀機制來建通道並架設服務 由於我們的服務會需要客端ip來進行分析 所以才會提出這個情境實現的可能性 因為我這邊純粹測試nginx確實可以做到真實ip的傳遞 那XRay也有涉及部份反代的功能 ip接收與發送兩個動作中 接收已經有做到了 那照理說發送出去應該也不會太困難才對 所以目前卡在一個比較小尷尬的局面 我想要利用xray支援vless等不錯的協議來傳遞流量 但只要整條鏈路有經過XRay的節點 真實ip就會卡在這一層 而若要放棄xray 那就無法享受相關協議支援以及回落、路由導轉等功能

> 不知道能不能让你明白，或许个别是有误的。 大部分科学上网都是拿节点的ip对解密后流量作类似NAT的地址翻译去转发流量，请求目标网站的从而绕过审查，不可能将客户端的IP直接透传到目标网络。根据路由协议的概念，只有路由转发才能直接将客户端的IP送达，而这个又会受防火墙所监控。或双端的程序做特殊配置（码代码）才能透传客户端真实IP，例如nginx/caddy之类或支持proxy protocol（HAProxy）的反代服务。 > > 就像家里的宽带一样，假定你内网地址是192.168.1.1，以下简称为a。出口网口（宽带拨号后）的地址是172.16.25.25，以下简称为b。目标地址是10.0.35.35，以下简称为c。 当a访问c时，c一般情况下获取到的客户端地址是b（NAT网关）。 但当b和c同时做了特殊配置（haproxy），就能把a的地址正确地传给c。 另外根據您的說明 我有先嘗試過一個做法 但目前是失敗的 想請問一下原因 基於您說的 目前可能只有nginx/caddy等反代服務可以傳遞真實ip 所以我有嘗試將outbound設定成freedom (配合redirect)或是 http 在設定address時 把流量導到127.0.0.1:8081 也就是本機端的nginx服務 預期nginx可以作為到目標網址前的中轉 做一些ip傳遞的處理 但實作的結果 nginx那邊都可以收到流量 但似乎都沒有辦法正常解析 伴隨的是400 bad request 故我想問的是...

> 从技术上来说是可行的，但配置会很复杂。 > > `客户端真实IP(a)->网关(b)->科学上网节点(c)[xray fallbacks，需要开启PROXY protocol]->nginx(c)->nginx再反代后端服务器(d)` 这样后端d就能看到b的真实IP地址，需要xray fallbacks正确配置和nginx的启用传递真实IP。 但如果是xray非回落的数据包就会被xray所处理，这样会导致后端d取得的是c的ip 优点：xray做前端能搞xtls-whateve，能灵活地创建科学上网服务。 缺点：xray fallbacks配置复杂，特别是要正确回落时，nginx反代时可能会出现莫名奇怪的古怪问题。 > > `客户端真实IP(a)->网关(b)->nginx(c)分流->nginx再反代后端服务器(d)` `      ->xray科学上网` 这种就能通过nginx的来反代后端服务器，从而将b的真实IP传递到d，而科学上网的流量就直接交给xray来处理。 优点：配置简单多了，不用搞xray fallbacks，nginx等能为不同的IP和网址配置不同的证书。 缺点：xray做后端就不能搞xtls-whatever了，失去了灵活创建科学上网的优势。 > > **补充一下，xray的出站是不支持PROXY protocol的，因此，xray的科学上网流量无法传递真实IP，除非有能力修改xray的源代码实现此功能，但需要此功能的用户极少。** 了解 感謝大大說明 目前有兩種情況 1. 透過fallback流到nginx的流量,這種未被xray經手處理的,客端ip可以正常傳,流量也可以被nginx正常收發...

有的 這個篇章我有先閱讀過 之前tlsSettings 若有設 certificates 都是針對「將xray作為服務端時」的inbound節點做設定 那如果今天是要搞雙向tls驗證 是要將tlsSettings的certificates, 設定在「將xray作為客戶端」的outbound裡面嗎？ 目前尚未找到這樣設定的先例 個人嘗試也並未試出效果