嘿，你遇到的这个问题确实有点诡异——明明是在测试.NET站点，结果新增new.blah.site.com域名绑定后，居然跳出了Tomcat的403错误，而且还找不到Tomcat的安装痕迹对吧？我给你整理几个实用的排查方向，一步步来定位问题：

1. 先确认域名解析是否正确 #

• 打开命令行，用ping new.blah.site.com看看解析到的IP地址，是不是和new.site.com、newa.site.com这些正常域名完全一致。如果解析到了别的IP，那大概率是Hosts文件或者本地DNS配置出了问题，导致请求被导去了有Tomcat的服务器。
• 检查本地hosts文件（Windows在C:\Windows\System32\drivers\etc\hosts，Linux/macOS在/etc/hosts），确认new.blah.site.com是不是正确指向了你的.NET站点服务器IP，有没有误写的情况。

2. 排查Apache反向代理的虚拟主机配置 #

• 如果你是用Apache做反向代理来转发请求到.NET站点，那得检查新增的子域名有没有在Apache的虚拟主机配置里正确设置。
• 找到Apache的httpd-vhosts.conf（或者对应站点的虚拟主机配置文件），对比正常域名的配置块，确认new.blah.site.com的ProxyPass/ProxyPassReverse是不是正确指向了.NET站点的地址，有没有不小心写成Tomcat的端口（比如8080）。
• 还要检查配置里的DocumentRoot权限设置，是不是因为路径不对或者权限不足导致了403。

3. 检查端口占用情况，揪出隐藏的Tomcat进程 #

• 有时候Tomcat可能没完全卸载干净，后台还在偷偷运行，抢占了请求。用命令排查端口：
  • Windows：netstat -ano | findstr ":80"（替换成你的站点端口），看看有没有陌生的进程ID，然后去任务管理器里对应PID，看看是不是Tomcat相关的进程。
  • Linux/macOS：lsof -i :80或者netstat -tulpn | grep :80，同样排查占用端口的进程。
• 如果找到Tomcat进程，直接终止它，然后重启你的.NET站点服务试试。

4. 确认.NET站点的绑定配置 #

• 打开你的.NET站点服务器（比如IIS或者Kestrel的配置文件），检查是否正确添加了new.blah.site.com的域名绑定。
  • 如果是IIS：打开IIS管理器，找到对应站点的“绑定”列表，确认新增的域名绑定的IP、端口、类型都和其他三个正常域名一致，有没有漏填或者选错选项。
  • 如果是Kestrel：检查appsettings.json里的Urls配置，或者启动时的绑定参数，确保包含了new.blah.site.com。

5. 排查残留的Tomcat配置或服务 #

• 就算你找不到Tomcat的安装目录，也可能有残留的服务或者配置文件在搞事：
  • Windows：打开服务管理器（运行services.msc），搜索有没有带“Tomcat”字样的服务，有的话直接禁用并停止。
  • Linux/macOS：检查/etc/systemd/system或者/Library/LaunchDaemons目录，看看有没有Tomcat的启动脚本，有的话删除并重新加载服务配置。
  • 另外，搜索本地有没有残留的server.xml文件，说不定某个程序还在引用这个Tomcat的配置文件。

小提示：出现Tomcat的403错误，说明你的请求确实被Tomcat接收到了，所以核心问题是搞清楚为什么new.blah.site.com的请求没有到达你的.NET站点，反而跑到了Tomcat那里。顺着这个方向排查，应该很快能找到根源。

内容的提问来源于stack exchange，提问作者Kolichikov