geoip:private matches chatgpt?

[pyk1998]

 "routing": {
        "domainStrategy": "IPIfNonMatch",
        "rules": [
            {
                "type": "field",
                "ip": [
                    "geoip:cn",
                    "geoip:private"
                ],
                "outboundTag": "block"
            }
        ]
  },

When I configure the server with dropping traffic of geoip:private, I cannot visit "chat.openai.com". Only when I delete "geoip:private", can I successfully visit the chatGPT. Should not "geoip:private" contain only private IP addresses? Same issue Here

[chika0801]

            "sniffing": {
                "enabled": true,
                "destOverride": [
                    "http",
                    "tls",
                    "quic"
                ]
            }

geoip:private will not conflict with chatgpt access.

Because I don't know if your client is a transparent proxy environment and exactly how to build the usage, and your server side complete configuration. Can only suggest that you add the domain sniffing parameters on the server side you test again.

[chika0801]

geoip:private Of course you can leave this parameter out. It comes from here https://github.com/v2fly/v2ray-examples

除非是适用于特定场景的模板，否则应当将 geoip:private 路由到 direct 出站 (服务端配置路由到 block 出站)

Unless it is a template for a specific scenario, geoip:private should be routed to direct outbound (server-side configuration routes to block outbound)

It's just an old tradition that probably, for you, doesn't make much practical sense.

[pyk1998]

            "sniffing": {
                "enabled": true,
                "destOverride": [
                    "http",
                    "tls",
                    "quic"
                ]
            }

geoip:private will not conflict with chatgpt access.

Because I don't know if your client is a transparent proxy environment and exactly how to build the usage, and your server side complete configuration. Can only suggest that you add the domain sniffing parameters on the server side you test again.

I have tried adding the domain sniffing on the server side, however the same problem. Delete "geoip:private" solves the problem, but I'm really curious about why.

Here is the full server configuration:

{
  "log": {
        "loglevel": "warning",
        "access": "/var/log/xray/access.log",
        "error": "/var/log/xray/error.log"
  },
  "routing": {
        "domainStrategy": "IPIfNonMatch",
        "rules": [
            {
                "type": "field",
                "ip": [
                    "geoip:cn",
                    "geoip:private"
                ],
                "outboundTag": "block"
            }
        ]
  },
  "inbounds": [ 
      {
          "listen": "0.0.0.0",
          "port": 10075,
          "protocol": "vless",
          "settings": {
              "clients": [
                  {
                      "id": "91xxxxxxxxxxx", 
                      "flow": "xtls-rprx-vision" 
                  }
              ],
              "decryption": "none"
          },
          "streamSettings": {
              "network": "tcp",
              "security": "reality",
              "realitySettings": {
                  "show": false, 
                  "dest": "www.lovelive-anime.jp:443", 
                  "xver": 0, 
                  "serverNames": [ 
                      "www.lovelive-anime.jp"
                  ],
                  "privateKey": "xxxxxxxxxxxx", 
                  "shortIds": [ 
                      "269b3", 
                      "0caex" 
                  ]
              }
          },
          "sniffing": {
                "enabled": true,
                "destOverride": [
                    "http",
                    "tls",
                    "quic"
                ]
          }
      }
  ],
  "outbounds": [
        {
            "protocol": "freedom",
            "tag": "direct"
        },
        {
            "protocol": "blackhole",
            "tag": "block"
        }
  ]
}

Here is the client side:

{
  "policy": {
    "system": {
      "statsOutboundUplink": true,
      "statsOutboundDownlink": true
    }
  },
  "log": {
    "access": "",
    "error": "",
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "socks",
      "port": 10808,
      "listen": "127.0.0.1",
      "protocol": "socks",
      "sniffing": {
        "enabled": true,
        "destOverride": [
          "http",
          "tls"
        ],
        "routeOnly": false
      },
      "settings": {
        "auth": "noauth",
        "udp": true,
        "allowTransparent": false
      }
    },
    {
      "tag": "http",
      "port": 10809,
      "listen": "127.0.0.1",
      "protocol": "http",
      "sniffing": {
        "enabled": true,
        "destOverride": [
          "http",
          "tls"
        ],
        "routeOnly": false
      },
      "settings": {
        "auth": "noauth",
        "udp": true,
        "allowTransparent": false
      }
    },
    {
      "tag": "api",
      "port": 53659,
      "listen": "127.0.0.1",
      "protocol": "dokodemo-door",
      "settings": {
        "udp": false,
        "address": "127.0.0.1",
        "allowTransparent": false
      }
    }
  ],
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "domain",
            "port": 10075,
            "users": [
              {
                "id": "xx",
                "alterId": 0,
                "email": "t@t.tt",
                "security": "auto",
                "encryption": "none",
                "flow": "xtls-rprx-vision"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "reality",
        "realitySettings": {
          "serverName": "www.lovelive-anime.jp",
          "fingerprint": "chrome",
          "show": false,
          "publicKey": "xx",
          "shortId": "xx",
          "spiderX": ""
        }
      },
      "mux": {
        "enabled": false,
        "concurrency": -1
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {
        "response": {
          "type": "http"
        }
      }
    }
  ],
  "stats": {},
  "api": {
    "tag": "api",
    "services": [
      "StatsService"
    ]
  },
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "inboundTag": [
          "api"
        ],
        "outboundTag": "api",
        "enabled": true
      },
      {
        "id": "4914962756982786296",
        "type": "field",
        "outboundTag": "direct",
        "domain": [
          "domain:example-example.com",
          "domain:example-example2.com"
        ],
        "enabled": true
      },
      {
        "id": "5670712549231961345",
        "type": "field",
        "outboundTag": "block",
        "domain": [
          "geosite:category-ads-all"
        ],
        "enabled": true
      },
      {
        "id": "5131650777333569302",
        "type": "field",
        "outboundTag": "direct",
        "domain": [
          "geosite:cn"
        ],
        "enabled": true
      },
      {
        "id": "5154131652501156663",
        "type": "field",
        "outboundTag": "direct",
        "ip": [
          "geoip:private",
          "geoip:cn"
        ],
        "enabled": true
      },
      {
        "id": "5564118234348705567",
        "type": "field",
        "port": "0-65535",
        "outboundTag": "proxy",
        "enabled": true
      }
    ]
  }
}

[chika0801]

Looking at your config file, I don't see the problem. You set the logging level to debug, visit chatgpt in your client browser, copy the logs from the relevant parts of the client and server, and paste them here for analysis. Or you can read the log processing flow yourself and try to analyze it yourself.

[pyk1998]

Looking at your config file, I don't see the problem. You set the logging level to debug, visit chatgpt in your client browser, copy the logs from the relevant parts of the client and server, and paste them here for analysis. Or you can read the log processing flow yourself and try to analyze it yourself.

Yes, it is quite wired. Look from the logs, it is the routing to blame. That's why I delete "geoip:private".

Here is the log from server side:

2023/09/08 20:15:02 [Info] [186666096] proxy/vless/inbound: received request for tcp:chat.openai.com:443
2023/09/08 20:15:02 [Info] [186666096] proxy/vless/encoding: Xtls Unpadding new block0 16 content 517 padding 464 0
2023/09/08 20:15:02 [Info] [186666096] proxy/vless/encoding: XtlsFilterTls found tls client hello! 517
2023/09/08 20:15:02 [Info] [186666096] app/dispatcher: sniffed domain: chat.openai.com
2023/09/08 20:15:02 [Info] [2344667753] proxy/vless/inbound: firstLen = 1186
2023/09/08 20:15:02 [Info] [2344667753] proxy/vless/inbound: received request for tcp:cdn.openai.com:443
2023/09/08 20:15:02 [Info] [2344667753] proxy/vless/encoding: Xtls Unpadding new block0 16 content 588 padding 556 0
2023/09/08 20:15:02 [Info] [2344667753] proxy/vless/encoding: XtlsFilterTls found tls client hello! 588
2023/09/08 20:15:02 [Info] [2344667753] app/dispatcher: sniffed domain: cdn.openai.com
2023/09/08 20:15:02 [Info] [186666096] app/dispatcher: taking detour [block] for [tcp:chat.openai.com:443]
2023/09/08 20:15:02 [Info] [186666096] app/proxyman/inbound: connection ends > proxy/vless/inbound: connection ends > io: read/write on closed pipe
2023/09/08 20:15:02 [Info] [2344667753] app/dispatcher: default route for tcp:cdn.openai.com:443
2023/09/08 20:15:02 [Info] [2344667753] transport/internet/tcp: dialing TCP to tcp:cdn.openai.com:443
2023/09/08 20:15:02 [Debug] transport/internet: dialing to tcp:cdn.openai.com:443
2023/09/08 20:15:02 [Info] [2344667753] proxy/freedom: connection opened to tcp:cdn.openai.com:443, local endpoint [myserverIP]:48580, remote endpoint 13.107.213.69:443

And the log from client side:

2023/09/08 20:15:02 [Info] [3190458857] proxy/http: request to Method [CONNECT] Host [chat.openai.com:443] with URL [//chat.openai.com:443]
2023/09/08 20:15:02 [Info] [3190458857] app/dispatcher: sniffed domain: chat.openai.com
2023/09/08 20:15:02 [Info] [3190458857] app/dispatcher: taking detour [proxy] for [tcp:chat.openai.com:443]
2023/09/08 20:15:02 127.0.0.1:65277 accepted //chat.openai.com:443 [http -> proxy]
2023/09/08 20:15:02 [Info] [3190458857] transport/internet/tcp: dialing TCP to [myserver.com]:10075
2023/09/08 20:15:02 [Debug] transport/internet: dialing to tcp:[myserver.com]:10075
2023/09/08 20:15:03 [Info] [3190458857] proxy/vless/outbound: tunneling request to tcp:chat.openai.com:443 via [myserver.com]:10075
2023/09/08 20:15:03 [Info] [3190458857] proxy/vless/encoding: XtlsFilterTls found tls client hello! 517
2023/09/08 20:15:03 [Info] [3190458857] proxy/vless/encoding: XtlsPadding 517 521 0
2023/09/08 20:15:04 [Info] [3190458857] app/proxyman/inbound: connection ends > proxy/http: connection ends > context canceled

[pyk1998]

I may find the problem. I ping "chat.openai.com" on the server, gives me "172.31.255.2", which is a local address. However, the result I get on the client is a global address "69.171.234.48". Maybe is the VPS provider's fault?

[chika0801]

Your vps merchant, may be using the dns unlock feature.

For example, try changing the dns address of the vps to 1.1.1.1 then try pinging chatgpt's domain on the vps.

[pyk1998]

Your vps merchant, may be using the dns unlock feature.

For example, try changing the dns address of the vps to 1.1.1.1 then try pinging chatgpt's domain on the vps.

Thank you so much for your help.

You are right, my VPS merchant uses this unlock technique.

I will bypass this address manually.

[chika0801]

This is commonly known as dns unlocking service provided by merchants to unlock chatgpt, netflix, etc.. As far as I know, many Chinese owned sites selling vps will offer it. I'm not sure what your merchant name is. I suggest you change to a different merchant. Usually you can unlock chatgpt as long as the vps ip quality of the merchant is not very poor.

[pyk1998]

This is commonly known as dns unlocking service provided by merchants to unlock chatgpt, netflix, etc.. As far as I know, many Chinese owned sites selling vps will offer it. I'm not sure what your merchant name is. I suggest you change to a different merchant. Usually you can unlock chatgpt as long as the vps ip quality of the merchant is not very poor.

It's Bandwagon. I've searched the web about this "172.31.255.2" IP, and many users are using it to unlock chatGPT. I also checked about the NetworkManager, it has already been set as the default DNS.

[chika0801]

With this merchant, the number of customers in the China region is high. The price of the vps it sells is not cheap. There is less negative news about the merchant. If you had said it was this merchant earlier, this situation you are experiencing is something I have heard others inquire about before. Now that you've named the merchant, I'm no longer surprised.