先描述一下问题现象，在本地测试运行一个java web网站，一切正常。但把网站部署到Linux服务器上后，发现登录出了问题，提示验证码输入不正确。登录时需要输入验证码，而验证码的原值是先存入session中的，然后点击【登录】后，会对比用户输入的验证码与原值，可此时查看日志发现，从session获取验证码为null。
起先本人惯性地认为是代码的问题，可换了几种写法之后，仍然存在这种现象，仔细想了下服务器与本地环境的差异，锁定了一个点，服务器的域名跟本地是不同的，服务器上的tomcat设置了虚拟主机，并使用nginx做了域名的反向代理。这里假设项目为siteExample，那么在本地运行时，url为“hettp://localhost:8080/siteExample”，在Linux服务器上，为了构造友好的网址，变为了“http://www.example.com”。
服务器上，指定了/www/apps为tomcat的项目发布目录。而在tomcat的server.xml文件中，关于虚拟主机的配置如下：
<Host appBase="/www/apps" autoDeploy="true" name="www.example.com" unpackWARs="true"> <Context docBase="/www/apps/siteExample" path="" /> </Host>
上面的配置中，Context元素的path属性之所以设为“”，是为了去除url中的项目名称，这样url就可以写为“http://www.example.com:8080”，然后再利用nginx的反向代理，去除url中的端口号即可。
考虑到域名的差异，我又仔细地查看了登录发送的请求，找了原因。在jsp页面里，我们写的资源包括链接的地址都应该是相对于当前url的地址，可前端人员在登录时发送的请求url写死了，写成了“/siteExample/login.do”，很显然在服务器上运行时，请求的绝对url为“http://www.example.com/siteExample/login.do”，而最终正确的url应该为“http://www.example.com/login.do”。验证码的原值存在了“http://www.example.com”的会话session中，而登录请求时，获取到的会话session是“http://www.example.com/siteExample”的，自然获取不到验证码的原值了。
可以看出，两个不同的域名，指向了相同物理位置的web项目，但产生的是两个不同的session会话。有兴趣的话可以研究下tomcat的运行原理。
