V2ray-core: WebSocket+TLS+nginx与Cloudflare CDN梯子，V2Ray伪装域名(host)的功能无法使用

Created on 4 Jan 2020 · 63Comments · Source: v2ray/v2ray-core

WebSocket+TLS+nginx与Cloudflare CDN梯子，V2Ray伪装域名(host)的功能无法使用

将V2RayN客户端中的伪装域名(host)设置成自己的域名www.myhostxxxx.top或者不设置，能够联网。
将其设置成伪装的，比如www.ted.com或者www.youku.com之类的，无法联网，客户端报错，见下面日志。

我确定：

时间没有问题。误差<1秒 。网上很多说时间问题的，但是我的情况不是。
使用自己真实的域名，是可以上网的 。使用伪装域名，成功上网半天时间，只有再不能上网。

1) 你正在使用哪个版本的 V2Ray？（如果服务器和客户端使用了不同版本，请注明）

服务器: debian 9 x64
V2Ray 4.22.1 (V2Fly, a community-driven edition of V2Ray.)

客户端：win10 x64
v2rayN 3.4
V2Ray 4.21.3 (V2Fly, a community-driven edition of V2Ray.)

2) 你的使用场景是什么？比如使用 Chrome 通过 Socks/VMess 代理观看 YouTube 视频。

V2Ray+WebSocket+TLS+nginx与Cloudflare CDN搭梯子，使用Chrome通过VMess代理，上Google。

3) 你看到的不正常的现象是什么？（请描述具体现象，比如访问超时，TLS 证书错误等）

正常：伪装域名(host)不填或者填写CDN上代理的域名，连接正常。
异常：伪装域名(host)填写其他的，比如www.ted.com或者www.youku.com等，无法连接。

4) 你期待看到的正确表现是怎样的？

伪装域名(host)填写任意的域名能够上网。

5) 请附上你的配置（提交 Issue 前请隐藏服务器端IP地址）。

v2ray服务器端配置:

{
  "inbounds": [
    {
      "port": 10000,
      "listen":"127.0.0.1",
      "protocol": "vmess",
      "settings": {
        "clients": [
          {
            "id": "xxxx-xxxxx-xxxx-xxx-xxxxx",
            "alterId": 64
          }
        ]
      },
      "streamSettings": {
        "network": "ws",
        "wsSettings": {
        "path": "/talks"
        }
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "blocked",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "blocked"
      }
    ]
  },
  "policy": {},
  "reverse": {},
  "transport": {}
}

v2ray客户端配置:

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vmess",
      "settings": {
        "vnext": [
          {
            "address": "www.myhostxxxx.top",
            "port": 443,
            "users": [
              {
                "id": "xxxx-xxxxx-xxxx-xxx-xxxxx",
                "alterId": 64
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "ws",
        "security": "tls",
        "tlsSettings": {
          "allowInsecure": true,
          "serverName": "www.myhostxxxx.top"
        },
        "wsSettings": {
          "connectionReuse": true,
          "path": "/talks",
          "headers": {
            "Host": "www.ted.com"  // 只要改成www.myhostxxxx.top或者不填，就可以上网
          }
        }
      }
    ]
  }
}

6) 请附上出错时软件输出的错误日志。在 Linux 中，日志通常在 /var/log/v2ray/error.log 文件中。

服务器端错误日志:

无错误：
2019/12/31 23:15:11 [Warning] v2ray.com/core: V2Ray 4.22.0 started
2019/12/31 23:49:08 [Warning] v2ray.com/core: V2Ray 4.22.0 started
2020/01/04 14:54:46 [Warning] v2ray.com/core: V2Ray 4.22.1 started   -- 最后一次升级

客户端错误日志:

2020/01/04 23:12:28 [Warning] failed to handler mux client connection > v2ray.com/core/proxy/vmess/outbound: failed to find an available destination > v2ray.com/core/common/retry: [v2ray.com/core/transport/internet/websocket: failed to dial WebSocket > v2ray.com/core/transport/internet/websocket: failed to dial to (wss://www.myhostxxxx.top/talks):  > remote error: tls: handshake failure v2ray.com/core/transport/internet/websocket: failed to dial WebSocket > v2ray.com/core/transport/internet/websocket: failed to dial to (wss://www.myhostxxxx.top/talks):  > read tcp 192.168.100.19:13255->104.18.53.237:443: i/o timeout v2ray.com/core/transport/internet/websocket: failed to dial WebSocket > v2ray.com/core/transport/internet/websocket: failed to dial to (wss://www.myhostxxxx.top/talks):  > remote error: tls: handshake failure] > v2ray.com/core/common/retry: all retry attempts failed

7) 请附上访问日志。在 Linux 中，日志通常在 /var/log/v2ray/access.log 文件中。

没有记录
2020/01/04 15:20:07 tcp:121.237.188.254:50594 accepted tcp:www.google.com.hk:443 [direct] 
2020/01/04 16:48:42 tcp:121.237.188.254:22966 accepted tcp:clients2.google.com:443 [direct] 
---23:12---左右的没有日志

浏览器错误：

500 Internal Privoxy Error
Privoxy encountered an error while processing your request:

Could not load template file no-server-data or one of its included components.

Please contact your proxy administrator.

If you are the proxy administrator, please put the required file(s)in the (confdir)/templates directory. The location of the (confdir) directory is specified in the main Privoxy config file. (It's typically the Privoxy install directory).

8) 其它相关的配置文件（如 Nginx）和相关日志。
nginx配置：

server {
  listen 443 ssl default_server;
  ssl on;
  ssl_certificate       /etc/myhostxxxx.top/myhostxxxx.pem;
  ssl_certificate_key   /etc/myhostxxxx.top/myhostxxxx.key;
  ssl_protocols         TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers           HIGH:!aNULL:!MD5;
  server_name           www.myhostxxxx.top;  # 这有次改成www.ted.com，客户端host也对应改成www.ted.com，联网成功过一天，后来就不行了，就改回了www.myhostxxxx.top

  location /talks { # 与v2ray的path对应
        proxy_redirect off;

        # redirect all HTTP traffic 
        proxy_pass http://127.0.0.1:10000;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Host $host;   # 改过$http_host，因为没什么用
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        # WebSocket support (nginx 1.4)
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
  }

  location / {
        root /opt/webroot/;
        #proxy_pass https://www.ted.com/;
  }
}

server {
  listen 80;
  location / {
        root /opt/webroot/;
        # proxy_pass https://www.ted.com/;
  }
}

9）Cloudflare设置

A记录： www.myhostxxxx.top 开启proxy（小黄云）或者关闭（小灰云）都试过，效果一样。
DNSSEC开启： TXT记录中设置dnssec的token。
TLS开启full模式。

10）时间已校准

时区：上海
3小时校准一次时间：
*/180 * * * * ntpdate time.nist.gov

Source

yaoha

Most helpful comment

谢谢解惑。这里说的使用CDN，拿CloudFlare举例，DNS only模式，算是使用CDN吗？

DNS Only的情况下，数据不经过CDN，直接发往你的服务器。但是这种情况下你的服务器IP地址会暴露。

谢谢解答。这下清楚了。即便使用CloudFlare的Proxied模式，看起来像是隐藏了真实IP，但实际上也能从很快找到真实IP

我试过了下，后背发凉，终归翻墙要佛系点。

路过说一句，我也是用这个：WebSocket+TLS+nginx，稳定地科学上网已经7-8个月，不是很明白为什么要怕墙去侦测到你的真IP？又要去搅个伪装域名？搅个伪装域名不就是此地无银三百两吗？

WS+TLS+NGINX的精粹，就是表面看来像是一个正常的https网站，V2ray躲在nginx后面，用来给你科学上网，墙无法(至少现在为止)检测出一台https网站后面是否运行着V2ray，而运行着的V2ray数据，完全是普通的https流量，墙无法识别https流量和科学上网流量，所以不会乱封，除非墙将VPS黑掉，直接进入系统，才能看到原来nginx后面运行着V2ray。

V2ray "3宝" ，隐闭性那么强(套上CDN就更强)，为何还要去搅什么隐藏IP？又要搅什么伪装域名？越搅得多无谓的东西，特征不也是会变得越明显吗？

我就不管啦，墙找到我的真IP要主动检测就来吧，反正墙没本事把我的VPS黑掉，那就无法知道我的网站后面是否运行着V2Ray，一台“普通的”HTTPS Web伺服器，只要不是将V2ray的科学上网账号用来卖钱，墙根本就懒得理你，何況牆就算想理也理不到，(侦测不到V2ray）简言之就是低调。

我的网站是https，表面上，网站的内容是对天朝歌功颂德，但实际上，网站后面运行着一个V2ray(WS+TLS+NGINX)，那又如何？至少，墙，暂时还没能检测出来，这才是完美的“伪装”。

所以无需搅什么伪装隐藏，现在我都是分了2个host，一个套了CDN，一个没套，平时用CDN，如果连线质量真的慢得太过份，我就用直连。

已运行差不多一年没出过任何问题。

cwyin7788 on 18 Jan 2020

👍8

All 63 comments

你这错误是时间不一致，你确定时间已经校准了吗？和客户端不能误差超过90秒

1265578519 on 4 Jan 2020

tls: handshake failure

You should use www.myhostxxxx.top in V2Ray Host config.
Because your cert is to www.myhostxxxx.top

Try and see if it works.

iochen on 5 Jan 2020

你这错误是时间不一致，你确定时间已经校准了吗？和客户端不能误差超过90秒

我确定、一定、以及肯定。误差<1秒。因为网上很多都是时间问题，但是我这个情况不是的。
我host中填写www.myhostxxxx.top是没有任何问题的。光凭这点就排除时间问题了。

yaoha on 5 Jan 2020

tls: handshake failure

You should use www.myhostxxxx.top in V2Ray Host config.
Because your cert is to www.myhostxxxx.top

Try and see if it works.

这样的话，V2rayN的伪装域名（host）)功能是摆设？因为我只能使用我的真实的host。
so that，V2rayN's host cheating function is not really working? beacase i can only use my REAL host。

yaoha on 5 Jan 2020

tls: handshake failure

You should use www.myhostxxxx.top in V2Ray Host config.
Because your cert is to www.myhostxxxx.top
Try and see if it works.

这样的话，V2rayN的伪装域名（host）)功能是摆设？因为我只能使用我的真实的host。
so that，V2rayN's host cheating function is not really working? beacase i can only use my REAL host。

server_name in nginx, and Host in V2Ray should be the same domain.

I haven't tested that before, try and see if it works.

iochen on 5 Jan 2020

tls: handshake failure

You should use www.myhostxxxx.top in V2Ray Host config.
Because your cert is to www.myhostxxxx.top
Try and see if it works.

这样的话，V2rayN的伪装域名（host）)功能是摆设？因为我只能使用我的真实的host。
so that，V2rayN's host cheating function is not really working? beacase i can only use my REAL host。

server_name in nginx, and Host in V2Ray should be the same domain.

I haven't tested that before, try and see if it works.

我试过多次，将nginx的server_name改成了伪装的www.ted.com，然后将v2rayN的host也改成www.ted.com。只成功过一次，大概半天时间，以后再也不行了。

I tried many times, changed the server_name of nginx to fake host www.ted.com, v2rayN's host is www.ted.com too. Only succeeded once, about half a day, and never again after that time.

yaoha on 5 Jan 2020

换一种方式提问，大家有成功使用假host的没？能否分享下配置。

Another way,has anyone successfully used fake hosts yet? Can you share the configuration？ Thx。

yaoha on 5 Jan 2020

这是我用的客户端配置，正常使用

{
"configVersion": 2,
"address": "104.28.23.1",
"port": 80,
"id": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"alterId": 64,
"security": "auto",
"network": "ws",
"remarks": "CDN-CF",
"headerType": "none",
"requestHost": "这里填写域名",
"path": "/",
"streamSecurity": "",
"allowInsecure": "",
"configType": 1,
"testResult": "",
"subid": ""
},

这是我的服务端配置
"port": 80,
"protocol": "vmess",
"settings": {
"clients": [
{
"id": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"level": 1,
"alterId": 64
}
]
},
"streamSettings": {
"network": "ws"
},
"sniffing": {
"enabled": true,
"destOverride": [
"http",
"tls"
]
}

1265578519 on 5 Jan 2020

As it worked once, the config should be Okay.
The reason may be that this traffic is strange.

If I connect to a https site, there are some steps below

In these steps, the ISP(or GFW) can see the host name doesn't match the cert common name.
So this may can explain why it once worked and isn't working now.

iochen on 5 Jan 2020

推荐你不要搞什么垃圾NGINX，不要做https，直接用就行了，因为到CDN-CF也是可以直接加密的，国外CDN到国外服务器回源，根本不需要加密，80即可

1265578519 on 5 Jan 2020

👎21 👍2

In ssl_certificate and ssl_certificate_key, you can use self-signed SSL cert, one is issued to www.ted.com, to see if it works.

iochen on 5 Jan 2020

As it worked once, the config should be Okay.
The reason may be that this traffic is strange.

If I connect to a https site, there are some steps below

In these steps, the ISP(or GFW) can see the host name doesn't match the cert common name.
So this may can explain why it once worked and isn't working now.

非常感谢你的细心解答！
very thanks！

yaoha on 5 Jan 2020

推荐你不要搞什么垃圾NGINX，不要做https，直接用就行了，因为到CDN-CF也是可以直接加密的，国外CDN到国外服务器回源，根本不需要加密，80即可

ok，你的方式我尝试下。

yaoha on 5 Jan 2020

In ssl_certificate and ssl_certificate_key, you can use self-signed SSL cert, one is issued to www.ted.com, to see if it works.

我试过了， not woking。the same error.

self-sined cert generator： https://www.selfsignedcertificate.com
nginx conf：

server {
  listen 443 ssl;
  ssl on;
  ssl_certificate       /etc/nginx/conf.d/ted/www.ted.com.cert;
  ssl_certificate_key   /etc/nginx/conf.d/ted/www.ted.com.key;
  ssl_protocols         TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers           HIGH:!aNULL:!MD5;
  server_name           www.ted.com;

  location /talks { # 与v2ray的path对应
        proxy_redirect off;

        # redirect all HTTP traffic 
        proxy_pass http://127.0.0.1:10000;  #与v2ray的监听地址端口对应
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        # WebSocket support (nginx 1.4)
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
  }
}

yaoha on 5 Jan 2020

你们为什么一定要用10000端口？
用个15372这类没意义的数字不行吗？
10000端口冲突的几率比其它数字高

另外，早期版本的nginx和最近版本的nginx路径设定方式不一样
尝试将 /talks 改为 /talks/ 或许有用

didila on 5 Jan 2020

换一种方式提问，大家有成功使用假host的没？能否分享下配置。

Another way,has anyone successfully used fake hosts yet? Can you share the configuration？ Thx。

有的，没用cdn，不过我记得我以前用cdn也行（也可能记错了），现在没电脑，没法贴配置，那个host，感觉就是在nginx那里判断一下就行，我的理解是一种口令这样子，感觉你的nginx配置没写对，应该加判断如果host对，才转发到v2ray，你看以看看这个网站有host那段，我也是那样写的，不过好像他写的有点小毛病，if那里写的时候，（啦什么都得空格隔开，我记得是这样
https://www.igfw.net/archives/13463

Alampdow on 5 Jan 2020

正常的. 用cdn的时候不可以乱报sni

k79e on 5 Jan 2020

👍6

你们为什么一定要用10000端口？
用个15372这类没意义的数字不行吗？
10000端口冲突的几率比其它数字高

另外，早期版本的nginx和最近版本的nginx路径设定方式不一样
尝试将 /talks 改为 /talks/ 或许有用

你可能没仔细看我的说明。只有在使用ws的host伪装才出问题（看起来大家都不怎么用这个功能）。常规的是ok的。

yaoha on 5 Jan 2020

我这使用完全正常，配置贴上去了，你试试吧，而且不推荐用nginx，web反代可以用kangle，自动支持ws，更友好

1265578519 on 5 Jan 2020

location / {
    root   /myhtml;
    index  index.html index.htm;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $http_host;
    if ( $http_host = "www.xxx.com" ){
        proxy_pass http://127.0.0.1:765;
    }
}

上边这是我nginx那块的配置，if中的host及为你要填的host，随便填，这样在不套cdn时可以用，但我不知到套cdn能不能，忘了

Alampdow on 6 Jan 2020

location / {
    root   /myhtml;
    index  index.html index.htm;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $http_host;
    if ( $http_host = "www.xxx.com" ){
        proxy_pass http://127.0.0.1:765;
    }
}
上边这是我nginx那块的配置，if中的host及为你要填的host，随便填，这样在不套cdn时可以用，但我不知到套cdn能不能，忘了

试过了，这种方式没有用。本质上跟我的配置是一样的。

yaoha on 6 Jan 2020

我这使用完全正常，配置贴上去了，你试试吧，而且不推荐用nginx，web反代可以用kangle，自动支持ws，更友好

你的配置是v2rayN的吗？怎么看起来长得跟我的不一样。我的问题应该出在tls对sni的校验上了。

yaoha on 6 Jan 2020

。。。。。
你的sni指向了ted，然后cdn怎么知道你要访问的是哪个ted，他会把你的数据发送到真实的ted服务器。。。。

JarmoHu on 7 Jan 2020

👍5

。。。。。
你的sni指向了ted，然后cdn怎么知道你要访问的是哪个ted，他会把你的数据发送到真实的ted服务器。。。。

请赐教，能否给个解决方案，使用websocket的sni来进行host欺骗，隐藏我的真实域名。

yaoha on 10 Jan 2020

我这使用完全正常，配置贴上去了，你试试吧，而且不推荐用nginx，web反代可以用kangle，自动支持ws，更友好

你的配置是v2rayN的吗？怎么看起来长得跟我的不一样。我的问题应该出在tls对sni的校验上了。

我的是v2ray-core的，v2rayN一样通用

1265578519 on 10 Jan 2020

。。。。。。
你的sni指向了ted，然后cdn怎么知道你要访问的是ted，他会把你的数据发送到真实的ted服务器。。。。

请赐教，能否给个解决方案，使用websocket的sni来进行主机欺骗，隐藏我的真实域名。

本来cdn为了安全考虑就不会让你乱报sni，怎么可能又能隐藏域名又能隐藏ip，这本来就是不现实的想法。要是想用host伪装就不要用cdn，本地自签名个假域名，或者干脆放弃tls。要是想用cdn隐藏ip就老老实实放弃伪装域名。v2ray只保障翻墙不保障匿名，想要绝对匿名请用tor，i2p。

aryMBLec on 12 Jan 2020

👍3

。。。。。
你的sni指向了ted，然后cdn怎么知道你要访问的是哪个ted，他会把你的数据发送到真实的ted服务器。。。。

请赐教，能否给个解决方案，使用websocket的sni来进行host欺骗，隐藏我的真实域名。

CDN就是根据SNI或者Host标头进行路由转发的，你伪装了Host，CDN根本就无法将数据转发到你的服务器。

ix64 on 13 Jan 2020

。。。。。。
你的sni指向了ted，然后cdn怎么知道你要访问的是ted，他会把你的数据发送到真实的ted服务器。。。。

请赐教，能否给个解决方案，使用websocket的sni来进行主机欺骗，隐藏我的真实域名。

本来cdn为了安全考虑就不会让你乱报sni，怎么可能又能隐藏域名又能隐藏ip，这本来就是不现实的想法。要是想用host伪装就不要用cdn，本地自签名个假域名，或者干脆放弃tls。要是想用cdn隐藏ip就老老实实放弃伪装域名。v2ray只保障翻墙不保障匿名，想要绝对匿名请用tor，i2p。

谢谢解惑。这里说的使用CDN，拿CloudFlare举例，DNS only模式，算是使用CDN吗？

yaoha on 13 Jan 2020

谢谢解惑。这里说的使用CDN，拿CloudFlare举例，DNS only模式，算是使用CDN吗？

DNS Only的情况下，数据不经过CDN，直接发往你的服务器。但是这种情况下你的服务器IP地址会暴露。

ix64 on 13 Jan 2020

谢谢解惑。这里说的使用CDN，拿CloudFlare举例，DNS only模式，算是使用CDN吗？

DNS Only的情况下，数据不经过CDN，直接发往你的服务器。但是这种情况下你的服务器IP地址会暴露。

谢谢解答。这下清楚了。即便使用CloudFlare的Proxied模式，看起来像是隐藏了真实IP，但实际上也能从很快找到真实IP

我试过了下，后背发凉，终归翻墙要佛系点。

yaoha on 13 Jan 2020

找IP哪有那么麻烦，，，发个投诉邮件给CF，2分钟不到他就把真实IP发回给你了

1265578519 on 13 Jan 2020

👍3

谢谢解惑。这里说的使用CDN，拿CloudFlare举例，DNS only模式，算是使用CDN吗？

DNS Only的情况下，数据不经过CDN，直接发往你的服务器。但是这种情况下你的服务器IP地址会暴露。

谢谢解答。这下清楚了。即便使用CloudFlare的Proxied模式，看起来像是隐藏了真实IP，但实际上也能从很快找到真实IP

我试过了下，后背发凉，终归翻墙要佛系点。

V2ray "3宝" ，隐闭性那么强(套上CDN就更强)，为何还要去搅什么隐藏IP？又要搅什么伪装域名？越搅得多无谓的东西，特征不也是会变得越明显吗？

所以无需搅什么伪装隐藏，现在我都是分了2个host，一个套了CDN，一个没套，平时用CDN，如果连线质量真的慢得太过份，我就用直连。

已运行差不多一年没出过任何问题。

cwyin7788 on 18 Jan 2020

👍8

谢谢解惑。这里说的使用CDN，拿CloudFlare举例，DNS only模式，算是使用CDN吗？

DNS Only的情况下，数据不经过CDN，直接发往你的服务器。但是这种情况下你的服务器IP地址会暴露。

谢谢解答。这下清楚了。即便使用CloudFlare的Proxied模式，看起来像是隐藏了真实IP，但实际上也能从很快找到真实IP
我试过了下，后背发凉，终归翻墙要佛系点。
路过说一句，我也是用这个：WebSocket+TLS+nginx，稳定地科学上网已经7-8个月，不是很明白为什么要怕墙去侦测到你的真IP？又要去搅个伪装域名？搅个伪装域名不就是此地无银三百两吗？

WS+TLS+NGINX的精粹，就是表面看来像是一个正常的https网站，V2ray躲在nginx后面，用来给你科学上网，墙无法(至少现在为止)检测出一台https网站后面是否运行着V2ray，而运行着的V2ray数据，完全是普通的https流量，墙无法识别https流量和科学上网流量，所以不会乱封，除非墙将VPS黑掉，直接进入系统，才能看到原来nginx后面运行着V2ray。

V2ray "3宝" ，隐闭性那么强(套上CDN就更强)，为何还要去搅什么隐藏IP？又要搅什么伪装域名？越搅得多无谓的东西，特征不也是会变得越明显吗？

我就不管啦，墙找到我的真IP要主动检测就来吧，反正墙没本事把我的VPS黑掉，那就无法知道我的网站后面是否运行着V2Ray，一台“普通的”HTTPS Web伺服器，只要不是将V2ray的科学上网账号用来卖钱，墙根本就懒得理你，就算想理也理不到，(侦测不到V2ray）简言之就是低调。

我的网站是https，表面上，网站的内容是对天朝歌功颂德，但实际上，网站后面运行着一个V2ray(WS+TLS+NGINX)，那又如何？至少，墙，暂时还没能检测出来，这才是完美的“伪装”。

所以无需搅什么伪装隐藏，现在我都是分了2个host，一个套了CDN，一个没套，平时用CDN，如果连线质量真的慢得太过份，我就用直连。

已运行差不多一年没出过任何问题。

谢谢这么详细的解答。我是刚上v2ray，对网上一些教程有些疑惑，有人提到伪装一个国内能访问的A国视频网站更加保险，所以我就试试看了，然后就遇到问题了。刚开始总想完美一点，真实域名和ip都都给隐藏掉，哈哈。听大家一说，自己这么一试，也就淡定了。

yaoha on 18 Jan 2020

谢谢解惑。这里说的使用CDN，拿CloudFlare举例，DNS only模式，算是使用CDN吗？

DNS Only的情况下，数据不经过CDN，直接发往你的服务器。但是这种情况下你的服务器IP地址会暴露。

谢谢解答。这下清楚了。即便使用CloudFlare的Proxied模式，看起来像是隐藏了真实IP，但实际上也能从很快找到真实IP
我试过了下，后背发凉，终归翻墙要佛系点。
路过说一句，我也是用这个：WebSocket+TLS+nginx，稳定地科学上网已经7-8个月，不是很明白为什么要怕墙去侦测到你的真IP？又要去搅个伪装域名？搅个伪装域名不就是此地无银三百两吗？

WS+TLS+NGINX的精粹，就是表面看来像是一个正常的https网站，V2ray躲在nginx后面，用来给你科学上网，墙无法(至少现在为止)检测出一台https网站后面是否运行着V2ray，而运行着的V2ray数据，完全是普通的https流量，墙无法识别https流量和科学上网流量，所以不会乱封，除非墙将VPS黑掉，直接进入系统，才能看到原来nginx后面运行着V2ray。
V2ray "3宝" ，隐闭性那么强(套上CDN就更强)，为何还要去搅什么隐藏IP？又要搅什么伪装域名？越搅得多无谓的东西，特征不也是会变得越明显吗？
我就不管啦，墙找到我的真IP要主动检测就来吧，反正墙没本事把我的VPS黑掉，那就无法知道我的网站后面是否运行着V2Ray，一台“普通的”HTTPS Web伺服器，只要不是将V2ray的科学上网账号用来卖钱，墙根本就懒得理你，就算想理也理不到，(侦测不到V2ray）简言之就是低调。
我的网站是https，表面上，网站的内容是对天朝歌功颂德，但实际上，网站后面运行着一个V2ray(WS+TLS+NGINX)，那又如何？至少，墙，暂时还没能检测出来，这才是完美的“伪装”。
所以无需搅什么伪装隐藏，现在我都是分了2个host，一个套了CDN，一个没套，平时用CDN，如果连线质量真的慢得太过份，我就用直连。
已运行差不多一年没出过任何问题。

谢谢这么详细的解答。我是刚上v2ray，对网上一些教程有些疑惑，有人提到伪装一个国内能访问的A国视频网站更加保险，所以我就试试看了，然后就遇到问题了。刚开始总想完美一点，真实域名和ip都都给隐藏掉，哈哈。听大家一说，自己这么一试，也就淡定了。

你架梯子的VPS，是互联网上的其中一分子，只要是曝露于互联网上的主机，墙要主动探测你的VPS，你也无法避免，既然都是避免不到，总会有被墙主动探测的一天，那就不用搅那么多，老老实实的由得墙自己去探测，反正V2ray “三宝”就是能抵御主动探测，只要侦测不到V2ray出来那就是成功了。

刚开始总想完美一点＜---WS+TLS+NGINX已经很完美，套上CDN就更完美，不需要画蛇添足的啦。

V2ray确实是一项伟大的专案，感激所有开发者所付出的努力。

cwyin7788 on 19 Jan 2020

搞了半天，，，原来你是想用别人的域名通过自己的域名cf cdn

1265578519 on 19 Jan 2020

谢谢解惑。这里说的使用CDN，拿CloudFlare举例，DNS only模式，算是使用CDN吗？

DNS Only的情况下，数据不经过CDN，直接发往你的服务器。但是这种情况下你的服务器IP地址会暴露。

谢谢解答。这下清楚了。即便使用CloudFlare的Proxied模式，看起来像是隐藏了真实IP，但实际上也能从很快找到真实IP
我试过了下，后背发凉，终归翻墙要佛系点。

路过说一句，我也是用这个：WebSocket+TLS+nginx，稳定地科学上网已经7-8个月，不是很明白为什么要怕墙去侦测到你的真IP？又要去搅个伪装域名？搅个伪装域名不就是此地无银三百两吗？

WS+TLS+NGINX的精粹，就是表面看来像是一个正常的https网站，V2ray躲在nginx后面，用来给你科学上网，墙无法(至少现在为止)检测出一台https网站后面是否运行着V2ray，而运行着的V2ray数据，完全是普通的https流量，墙无法识别https流量和科学上网流量，所以不会乱封，除非墙将VPS黑掉，直接进入系统，才能看到原来nginx后面运行着V2ray。

V2ray "3宝" ，隐闭性那么强(套上CDN就更强)，为何还要去搅什么隐藏IP？又要搅什么伪装域名？越搅得多无谓的东西，特征不也是会变得越明显吗？

我就不管啦，墙找到我的真IP要主动检测就来吧，反正墙没本事把我的VPS黑掉，那就无法知道我的网站后面是否运行着V2Ray，一台“普通的”HTTPS Web伺服器，只要不是将V2ray的科学上网账号用来卖钱，墙根本就懒得理你，何況牆就算想理也理不到，(侦测不到V2ray）简言之就是低调。

我的网站是https，表面上，网站的内容是对天朝歌功颂德，但实际上，网站后面运行着一个V2ray(WS+TLS+NGINX)，那又如何？至少，墙，暂时还没能检测出来，这才是完美的“伪装”。

所以无需搅什么伪装隐藏，现在我都是分了2个host，一个套了CDN，一个没套，平时用CDN，如果连线质量真的慢得太过份，我就用直连。

已运行差不多一年没出过任何问题。

你这是体量太小罢了，我这一天几百g，还是敏感环境使用。不买专线的低成本办法就是买cf的付费服务。

0x0004 on 2 Feb 2020

看个人玩家简直都像弟弟

0x0004 on 2 Feb 2020

谢谢解惑。这里说的使用CDN，拿CloudFlare举例，DNS only模式，算是使用CDN吗？

DNS Only的情况下，数据不经过CDN，直接发往你的服务器。但是这种情况下你的服务器IP地址会暴露。

谢谢解答。这下清楚了。即便使用CloudFlare的Proxied模式，看起来像是隐藏了真实IP，但实际上也能从很快找到真实IP
我试过了下，后背发凉，终归翻墙要佛系点。

路过说一句，我也是用这个：WebSocket+TLS+nginx，稳定地科学上网已经7-8个月，不是很明白为什么要怕墙去侦测到你的真IP？又要去搅个伪装域名？搅个伪装域名不就是此地无银三百两吗？
WS+TLS+NGINX的精粹，就是表面看来像是一个正常的https网站，V2ray躲在nginx后面，用来给你科学上网，墙无法(至少现在为止)检测出一台https网站后面是否运行着V2ray，而运行着的V2ray数据，完全是普通的https流量，墙无法识别https流量和科学上网流量，所以不会乱封，除非墙将VPS黑掉，直接进入系统，才能看到原来nginx后面运行着V2ray。
V2ray "3宝" ，隐闭性那么强(套上CDN就更强)，为何还要去搅什么隐藏IP？又要搅什么伪装域名？越搅得多无谓的东西，特征不也是会变得越明显吗？
我就不管啦，墙找到我的真IP要主动检测就来吧，反正墙没本事把我的VPS黑掉，那就无法知道我的网站后面是否运行着V2Ray，一台“普通的”HTTPS Web伺服器，只要不是将V2ray的科学上网账号用来卖钱，墙根本就懒得理你，何況牆就算想理也理不到，(侦测不到V2ray）简言之就是低调。
我的网站是https，表面上，网站的内容是对天朝歌功颂德，但实际上，网站后面运行着一个V2ray(WS+TLS+NGINX)，那又如何？至少，墙，暂时还没能检测出来，这才是完美的“伪装”。
所以无需搅什么伪装隐藏，现在我都是分了2个host，一个套了CDN，一个没套，平时用CDN，如果连线质量真的慢得太过份，我就用直连。
已运行差不多一年没出过任何问题。

你这是体量太小罢了，我这一天几百g，还是敏感环境使用。不买专线的低成本办法就是买cf的付费服务。

墙根本就不理你是一天几百GB还是一天1GB，只要你人在大陆，要连接墙外网站，墙就㑹侦测科学上网的流量或者主动检测主机，如果检测到主机架了梯子就封，我是香港人，家里的IP是固定的，所以我只要用3百多块买一台Raspberry PI，装个SSR / V2ray，我上大陆时就可以用自己家里的Pi主机科学上网，速度我不追求特别的快，有10-20Mb速度够了，最重要是稳定，这亦是我买Pi的原因。

以前我在自己家里架了SSR，我上深圳一天，用自己的SSR没错是可以科学上网的，用一整天都没问题，但我没用多少流量，可能几百MB至1GB吧？但当我从深圳回港后，过一两天，我香港的IP就㑹被墙封掉，不需要上大陆就知道，因为baidu、taobao、boc.cn、等等一大堆内地网站我全部都上不到，(用VPN转了IP就可以)，大约一个月后才㑹解封我的IP，我已经试过3-4次这样了。

回港后过一两天墙才来封我的IP，我不知道是墙的主动检测还是从流量上被识别了，总之根据我的使用经验，别说一天几百GB流量了，就算只有1GB流量墙只要检测到你在科学上网都㑹把你的IP封掉。

你一天几百GB没被封不是因为你付费给CF，是因为你没被墙检测出来而已。

同样，我转用v2ray后，用了差不多一年我的IP都不死，也是因为没被墙检测出来而已。

cwyin7788 on 2 Feb 2020

谢谢解惑。这里说的使用CDN，拿CloudFlare举例，DNS only模式，算是使用CDN吗？

DNS Only的情况下，数据不经过CDN，直接发往你的服务器。但是这种情况下你的服务器IP地址会暴露。

谢谢解答。这下清楚了。即便使用CloudFlare的Proxied模式，看起来像是隐藏了真实IP，但实际上也能从很快找到真实IP
我试过了下，后背发凉，终归翻墙要佛系点。

路过说一句，我也是用这个：WebSocket+TLS+nginx，稳定地科学上网已经7-8个月，不是很明白为什么要怕墙去侦测到你的真IP？又要去搅个伪装域名？搅个伪装域名不就是此地无银三百两吗？
WS+TLS+NGINX的精粹，就是表面看来像是一个正常的https网站，V2ray躲在nginx后面，用来给你科学上网，墙无法(至少现在为止)检测出一台https网站后面是否运行着V2ray，而运行着的V2ray数据，完全是普通的https流量，墙无法识别https流量和科学上网流量，所以不会乱封，除非墙将VPS黑掉，直接进入系统，才能看到原来nginx后面运行着V2ray。
V2ray "3宝" ，隐闭性那么强(套上CDN就更强)，为何还要去搅什么隐藏IP？又要搅什么伪装域名？越搅得多无谓的东西，特征不也是会变得越明显吗？
我就不管啦，墙找到我的真IP要主动检测就来吧，反正墙没本事把我的VPS黑掉，那就无法知道我的网站后面是否运行着V2Ray，一台“普通的”HTTPS Web伺服器，只要不是将V2ray的科学上网账号用来卖钱，墙根本就懒得理你，何況牆就算想理也理不到，(侦测不到V2ray）简言之就是低调。
我的网站是https，表面上，网站的内容是对天朝歌功颂德，但实际上，网站后面运行着一个V2ray(WS+TLS+NGINX)，那又如何？至少，墙，暂时还没能检测出来，这才是完美的“伪装”。
所以无需搅什么伪装隐藏，现在我都是分了2个host，一个套了CDN，一个没套，平时用CDN，如果连线质量真的慢得太过份，我就用直连。
已运行差不多一年没出过任何问题。

你这是体量太小罢了，我这一天几百g，还是敏感环境使用。不买专线的低成本办法就是买cf的付费服务。

墙根本就不理你是一天几百GB还是一天1GB，只要你人在大陆，要连接墙外网站，墙就㑹侦测科学上网的流量或者主动检测主机，如果检测到主机架了梯子就封，我是香港人，家里的IP是固定的，所以我只要用3百多块买一台Raspberry PI，装个SSR / V2ray，我上大陆时就可以用自己家里的Pi主机科学上网，速度我不追求特别的快，有10-20Mb速度够了，最重要是稳定，这亦是我买Pi的原因。

以前我在自己家里架了SSR，我上深圳一天，用自己的SSR没错是可以科学上网的，用一整天都没问题，但我没用多少流量，可能几百MB至1GB吧？但当我从深圳回港后，过一两天，我香港的IP就㑹被墙封掉，不需要上大陆就知道，因为baidu、taobao、boc.cn、等等一大堆内地网站我全部都上不到，(用VPN转了IP就可以)，大约一个月后才㑹解封我的IP，我已经试过3-4次这样了。

回港后过一两天墙才来封我的IP，我不知道是墙的主动检测还是从流量上被识别了，总之根据我的使用经验，别说一天几百GB流量了，就算只有1GB流量墙只要检测到你在科学上网都㑹把你的IP封掉。

你一天几百GB不是因为你付费给CF，是因为你没被墙检测出来而已。

同样，我转用v2ray后，用了差不多一年我的IP都不死，也是因为没被墙检测出来而已。

什么v2ray配置能不死，愿闻其详。

0x0004 on 2 Feb 2020

@0x0004 默认的TCP模式，他是完全没有特征的，墙是无法识别此流量，针对v2ray的tcp模式，也就是你所谓的流量大小检测了。如果是ss ssr那些，可以用抓包软件抓包，有个固定的特征头部，自然也就被识别了
如果TCP模式因为流量巨大被判断检测，那么可以使用ws模式伪装成网页流量，这么一来墙也没有任何办法检测了，除非国际光缆海外流量一刀切

1265578519 on 2 Feb 2020

👎1

@0x0004 默认的TCP模式，他是完全没有特征的，墙是无法识别此流量，针对v2ray的tcp模式，也就是你所谓的流量大小检测了。如果是ss ssr那些，可以用抓包软件抓包，有个固定的特征头部，自然也就被识别了

kcp伪装bt呢？效果如何

0x0004 on 2 Feb 2020

@0x0004 别说bt，正常的transmission，utorrent等bt服务器，全部一刀切，参考去年6月份，所有PT站种子挂机的服务器，全被墙，做UDP是不现实的，毕竟全球任何一个机房，运营商，都不欢迎UDP流量
既然正常的BT客户端都没法避免被墙，就别说伪装后的了

1265578519 on 2 Feb 2020

👎1

@0x0004 默认的TCP模式，他是完全没有特征的，墙是无法识别此流量，针对v2ray的tcp模式，也就是你所谓的流量大小检测了。如果是ss ssr那些，可以用抓包软件抓包，有个固定的特征头部，自然也就被识别了
如果TCP模式因为流量巨大被判断检测，那么可以使用ws模式伪装成网页流量，这么一来墙也没有任何办法检测了，除非国际光缆海外流量一刀切

那ws需要加tls吗

0x0004 on 2 Feb 2020

@0x0004 就目前阶段来说，没有增加tls的必要，增加tls还会加重服务端附带，更高的cpu使用率，大流量环境下不现实
就和我之前说的，除非一刀切海外流量，否则检测到就是网页流量
关于SS特征方面，所以现在ss更新了加了个aead模式，就是去掉了特征

这个模式，抓包抓不到特征的
什么aes256cfb都有非常明显的固定特征轻松识别

1265578519 on 2 Feb 2020

👎1

什么v2ray配置能不死，愿闻其详。

V2ray + WS + TLS + NGINX + (免费cloudflare CDN)，我不追求速度，能看到youtube便可以了，所以我㑹先用CDN，但如果大陆Wifi的连线品质真的太差，慢到不能忍受，我㑹用直连(不套CDN)，直接连回家里的Pi，所以正如之前所说，我分了2个hosts，一个套上CDN，一个没套。

当然我2个hosts都有一个正常的https网站做伪装，而科学上网的流量亦全都走https (443)

我上年5月发现到V2ray这个伟大的专案后就开始研究设置并转用，到今年2月，我的IP从来没死过。

cwyin7788 on 2 Feb 2020

@0x0004 默认的TCP模式，他是完全没有特征的，墙是无法识别此流量，针对v2ray的tcp模式，也就是你所谓的流量大小检测了。如果是ss ssr那些，可以用抓包软件抓包，有个固定的特征头部，自然也就被识别了
如果TCP模式因为流量巨大被判断检测，那么可以使用ws模式伪装成网页流量，这么一来墙也没有任何办法检测了，除非国际光缆海外流量一刀切

转用v2ray后，一开始就已经是用WS+TLS+NGINX到现在，没用过TCP，非常稳定。

cwyin7788 on 2 Feb 2020

@i553041 嗯，tcp主要的特征就是没有特征，，所以流量大了很有可能被干掉。如果一天几百G还是ws

1265578519 on 2 Feb 2020

👎1

所以所以有没有软件可以分流TCP和http，就是如果是接受到http访问就给网站，如果监视到v2ray的TCP协议就转发到v2ray的监听端口

JarmoHu on 2 Feb 2020

@hustarbor 你是一台服务器做网站和v2ray？用任何一个软件都能反代

1265578519 on 2 Feb 2020

这样的话，V2rayN的伪装域名（host）)功能是摆设？因为我只能使用我的真实的host。

我觉得你指的是 Domain fronting，这并不是 V2ray 的功能。

嗯，tcp主要的特征就是没有特征，，所以流量大了很有可能被干掉。如果一天几百G还是ws

你对 TCP 似乎存在很大的误解，然而你反复强调的“TCP 流量没有特征”不是事实。最基础的数据包包长、时序都是流量分类的依据。另外照你的论点，本项目可能就不会存在了。

毕竟全球任何一个机房，运营商，都不欢迎UDP流量

DNS、NTP 都是常见的 UDP 流量，不要拿自己小众的协议说事。@1265578519

就目前阶段来说，没有增加tls的必要，增加tls还会加重服务端附带

第一，并不会有性能问题，第二，TLS 已是主流流量，使用它能避免你被归为小众。

tomac4t on 3 Feb 2020

👍2

最近发现墙开始用新的方法屏蔽IP了，我的一台gcp之前caddy+ws+tls稳定活了4个月，这个月开始只要连接超过一段时间或者说发现家宽长期连接一个海外IP的话就会直接干扰，ping不通，家宽重新拨号之后有可能正常一会，油管嗨个把小时就开始速度往下掉，然后就一样ping不通了，一怒之下把服务器重置v2ray直接443做tls+ws，同样过一段时间就ping不通，现在只能套CDN苟活。非常时期墙根本不管你是否科学上网也不管你什么流量，只要长时间连接一个墙外IP就会开始阻断

Lantrancy on 7 Feb 2020

👍2

最近发现墙开始用新的方法屏蔽IP了，我的一台gcp之前caddy+ws+tls稳定活了4个月，这个月开始只要连接超过一段时间或者说发现家宽长期连接一个海外IP的话就会直接干扰，ping不通，家宽重新拨号之后有可能正常一会，油管嗨个把小时就开始速度往下掉，然后就一样ping不通了，一怒之下把服务器重置v2ray直接443做tls+ws，同样过一段时间就ping不通，现在只能套CDN苟活。非常时期墙根本不管你是否科学上网也不管你什么流量，只要长时间连接一个墙外IP就会开始阻断

㑹不㑹是客戶端問題？因為類似的情況有其他人試過了：

https://github.com/v2ray/v2ray-core/issues/2198

手機客戶端和電腦客戶端都出現同一情況嗎？

只要长时间连接一个墙外IP就会开始阻断＜－－－如果真是這樣，㑹不㑹只是針對一些出名的雲平台 / VPS供應商IP？

cwyin7788 on 8 Feb 2020

最近发现墙开始用新的方法屏蔽IP了，我的一台gcp之前caddy+ws+tls稳定活了4个月，这个月开始只要连接超过一段时间或者说发现家宽长期连接一个海外IP的话就会直接干扰，ping不通，家宽重新拨号之后有可能正常一会，油管嗨个把小时就开始速度往下掉，然后就一样ping不通了，一怒之下把服务器重置v2ray直接443做tls+ws，同样过一段时间就ping不通，现在只能套CDN苟活。非常时期墙根本不管你是否科学上网也不管你什么流量，只要长时间连接一个墙外IP就会开始阻断

㑹不㑹是客戶端問題？因為類似的情況有其他人試過了：

2198

手機客戶端和電腦客戶端都出現同一情況嗎？

只要长时间连接一个墙外IP就会开始阻断＜－－－如果真是這樣，㑹不㑹只是針對一些出名的雲平台 / VPS供應商IP？

手机和PC都一样，连电信4G都一样，断流之后直接ping服务器都不通了，本来几十ping的机器变成七八十丢包率+200多ping，再接着就直接不通了，这套配置用了几个月了，没有改过配置，电脑也是干净重装过的没有任何国产软件，目测不是vps网段被针对了就是墙的策略改了

Lantrancy on 8 Feb 2020

最近发现墙开始用新的方法屏蔽IP了，我的一台gcp之前caddy+ws+tls稳定活了4个月，这个月开始只要连接超过一段时间或者说发现家宽长期连接一个海外IP的话就会直接干扰，ping不通，家宽重新拨号之后有可能正常一会，油管嗨个把小时就开始速度往下掉，然后就一样ping不通了，一怒之下把服务器重置v2ray直接443做tls+ws，同样过一段时间就ping不通，现在只能套CDN苟活。非常时期墙根本不管你是否科学上网也不管你什么流量，只要长时间连接一个墙外IP就会开始阻断

㑹不㑹是客戶端問題？因為類似的情況有其他人試過了：

2198

手機客戶端和電腦客戶端都出現同一情況嗎？

只要长时间连接一个墙外IP就会开始阻断＜－－－如果真是這樣，㑹不㑹只是針對一些出名的雲平台 / VPS供應商IP？

猜测高墙目前针对热门机房ip段进行了高强度的干扰。
目前azure的hk节点，搭建网站开启https，本地多刷新几次都会被阻断，过10分钟左右恢复正常(用17ce等工具测速前几次没问题，但是测4-5次之后，大陆全部无法连接，海外正常)。
今天下午找了半天原因，才发现是墙的问题。
ps: 未安装过v2等工具，单纯用来建站的

Tai7sy on 8 Feb 2020

Azure和gce hk都非常敏感，远一点就好了

kslr on 8 Feb 2020

所以为啥ip都ping不通了，又好了，过了多长时间好的...最近我4个挂了３个，ip被ban，唯一剩的一个gcp hk tcp被阻，我现在只有cdn救活那３个，然后gcp用换ip方法来苟火。
v２ray+ws+tls都不稳了？这如果不是热门机房倒一片的话，就有点儿疯狂了，我还希望着花点钱换ip，然后用ws呢，cdn还是太慢，cn２ gia完全没用了。

suhuaixing on 13 Feb 2020

偏离主题了

kslr on 13 Feb 2020

tls: handshake failure

You should use www.myhostxxxx.top in V2Ray Host config.
Because your cert is to www.myhostxxxx.top
Try and see if it works.

这样的话，V2rayN的伪装域名（host）)功能是摆设？因为我只能使用我的真实的host。
so that，V2rayN's host cheating function is not really working? beacase i can only use my REAL host。

我也坐标魔都也曾碰到同样得问题偶然看到这里现在结帖实际你自己已经弄得很清楚了

edorphin on 11 May 2020

流量大户来现身说法了，客户六七百个，日均流量还是几百g，在某些敏感地区的敏感单位v2ray早不好使了，不管是tcp还是ws+tls，这种极端场合只有一条路行得通，不过不能说，知道的人应该也有。
老百姓在家上外网，这叫第一层；老百姓在xj上外网，这是第二层；jc在gaj上外网，这是第三层；jc在xj gaj上外网，这是第四层；不可描述在xj 的不可描述上外网，这是第五层。
目前只有某个方法，能在第五层活下来，v2ray tcp 偶尔会断体验不好，其他的(不是针对谁，是所有)根本不好使。论网络审查，bj、xz都是弟弟。

0x0004 on 12 May 2020

👀3 👎2 ❤1

看不懂麻烦打中文

1265578519 on 12 May 2020

👍2 👎1

@yaoha
我在搭建v2ray的时候，也有和作者一样的问题，虽然我在服务端已经设置了伪装域名，例如liyaxxx.com，但是在V2RayN客户端中的伪装域名(host)只有设置成自己的域名www.myhostxxxx.top或者空着，才能代理上网，如果伪装域名填写liyaxxx.com，无法代理上网。
经过折腾后发现，伪装域名可以理解为反代，在浏览器输入自己的域名，里面的内容是反代网站liyaxxx.com的，因此我认为伪装域名的作用主要是在服务端，能够实现反代的效果，在客户端伪装域名这一行只能填写自己的真实域名www.myhostxxxx.top或者空着，但是分流路径不能空着，需要填写在服务端设置的（例如/1dg)。
设置伪装域名后，有这样一个效果：
在浏览器访问自己的域名www.myhostxxxx.top, 内容和liyaxxx.com的一致；
在浏览器访问带分流路径的域名www.myhostxxxx.top/1dg, 网站显示 bad request（因为我没有安装web）。
伪装域名还是有点效果的，至少让墙访问域名的时候，会认为这是一个真实的网站，因为里面有内容（虽然是反代的）。

ikkyusan123 on 20 May 2020

@yaoha
我在搭建v2ray的时候，也有和作者一样的问题，虽然我在服务端已经设置了伪装域名，例如liyaxxx.com，但是在V2RayN客户端中的伪装域名(host)只有设置成自己的域名www.myhostxxxx.top或者空着，才能代理上网，如果伪装域名填写liyaxxx.com，无法代理上网。
经过折腾后发现，伪装域名可以理解为反代，在浏览器输入自己的域名，里面的内容是反代网站liyaxxx.com的，因此我认为伪装域名的作用主要是在服务端，能够实现反代的效果，在客户端伪装域名这一行只能填写自己的真实域名www.myhostxxxx.top或者空着，但是分流路径不能空着，需要填写在服务端设置的（例如/1dg)。
设置伪装域名后，有这样一个效果：
在浏览器访问自己的域名www.myhostxxxx.top, 内容和liyaxxx.com的一致；
在浏览器访问带分流路径的域名www.myhostxxxx.top/1dg, 网站显示 bad request（因为我没有安装web）。
伪装域名还是有点效果的，至少让墙访问域名的时候，会认为这是一个真实的网站，因为里面有内容（虽然是反代的）。

那你用的应该是233脚本了，而且是选择了自动配置caddy，反代是caddy配置文件起了作用，你在caddyfile里会看到一行proxy / liyaxxx.com，就是这行起的作用