解决Nginx端口冲突的排查方法示例
问题描述
一个Spring + Angular前后端分离的项目，使用Nginx进行数据转发。
Nginx监听端口8100，前台端口4200，后台端口8080。
像往常一样，提前配置好MySQL、配置好Redis，引入项目的Nginx配置文件，然后启动前台、后台，成功。
接下来出现了问题：前台发起的请求，只有极少数能被后台接收到，大部分都是404，随着在浏览器中的点击，控制台不断的出现404。
如果只是404，那问题就很简单，很大可能是Nginx端口转发设置错了。但它的神奇之处就在于，还有那么几次请求，是能到达后台的。
（上图中，显示保存成功的时候，后台确实输出了相关的控制台信息）
其他的小伙伴都没有出现这个问题，于是开始排查。
排查过程
为了搞清楚是 后端 的问题还是 Nginx 转发的问题，需要先从浏览器的NetWork中看一下这个404是后台返回的还是Nginx返回的。
经过查看，发现是Nginx返回的。如果是后台返回的404，会把错误信息写在HTTP请求头中。
先查看监听端口是否有冲突，使用nginx -T可以查看完整的Nginx配置文件，包括引入的外部文件。
// 测试配置文件是否正确，并输出完整的配置文件 nginx -T
在输出的结果中，只看到一个8100，说明虽然引入了多个项目，但并没有出现监听端口冲突。
然后笔者打算从Nginx日志中寻找一些蛛丝马迹。
开启Nginx的日志模式之后，查看日志文件，发现了上千条访问记录
大多数都是404，少数是200，但日志并没有提供什么有用的信息。
最终，还是在配置文件中发现了问题：
使用HomeBrew安装的Nginx，它的全局配置文件中，默认的监听端口就是8080，而项目后端占用的端口也是8080。
虽然对于端口监听和端口占用的原理不是很了解，至少可以知道，由于Nginx监听了8080端口，有一部分请求被发到了Nginx自己那里，另一部分才是发送到后台。
所以，修改全局配置文件，改掉默认端口，问题解决。
// 修改配置文件 sudo vim /usr/local/etc/nginx/nginx.conf // 测试配置文件 nginx -t // 重启Nginx nginx -s reload
终于，所有的请求都能达到后台了。
总结
在一开始学习XAMPP的时候，就经常听到：“如果80端口冲突，就把端口改掉，比如改成8080”。
可是当8080成为了我们的习惯之后，有些项目也会使用这个端口...因此就要解决冲突问题了。
以后更改默认端口的时候，建议改成一个不可能用到的端口，比如10000以上的端口号，避免和项目的端口产生冲突。
到此这篇关于解决Nginx端口冲突的排查方法示例的文章就介绍到这了,更多相关Nginx端口冲突的排查方法内容请搜索小牛知识库以前的文章或继续浏览下面的相关文章希望大家以后多多支持小牛知识库！
-
Windows 用tutorial进行的操作 若要进行pull操作，请右击tutorial目录，并选择‘拉取’。 用tutorial进行的操作 在以下画面点击‘确定’。 用tutorial进行的操作 我们看到画面上的警告信息表示自动合并失败。请点击‘关闭’以退出窗口。 用tutorial进行的操作 若您确认变更，请点击‘Yes’。 用tutorial进行的操作 TortoiseGit告诉我们：因"
-
在上一个页面我们提及到，执行合并即可自动合并Git修改的部分。但是，也存在无法自动合并的情况。 如果远程数据库和本地数据库的同一个地方都发生了修改的情况下，因为无法自动判断要选用哪一个修改，所以就会发生冲突。 Git会在发生冲突的地方修改文件的内容，如下图。所以我们需要手动修正冲突。 ==分割线上方是本地数据库的内容, 下方是远程数据库的编辑内容。 如下图所示，修正所有冲突的地方之后，执行提交。
-
解决冲突 CVS使用内联“冲突标志”来标记冲突，并且在更新时打印C。历史上讲，这导致了许多问题，因为CVS做得还不够。许多用户在它们快速闪过终端时忘记（或没有看到）C，即使出现了冲突标记，他们也经常忘记，然后提交了带有冲突标记的文件。 Subversion通过让冲突更明显来解决这个问题，它记住一个文件是处于冲突状态，在你运行svn resolved之前不会允许你提交修改，详情见“解决冲突（合并别人
-
本文向大家介绍Android listview的滑动冲突解决方法，包括了Android listview的滑动冲突解决方法的使用技巧和注意事项，需要的朋友参考一下 Android listview的滑动冲突解决方法 在Android开发的过程中，有时候会遇到子控件和父控件都要滑动的情况，尤其是当子控件为listview的时候。就比如在一个ScrollView里有一个listview，这种情况较常见
-
两个客户端同时修改同一个文件， 改动同一个位置，发生冲突情况。 这时如果一个用户使用commit 提交文件就会提示已经过时（out of date）： 说明另一个人可能被别人改动过！ 这时需要update更新该文件，更新后效果如下： db.properties 将本地和服务器合并到一起的文件 （不要直接看） db.properties.mine 我本地自己修改后的文件 d
-
上一章介绍了Git协议，并且使用本地协议来模拟一个远程的版本库，以两个不同用户的身份检出该版本库，和该远程版本库进行交互——交换数据、协同工作。在上一章的协同中只遇到了一个小小的麻烦——非快进式推送，可以通过执行PULL（拉回）操作，成功完成合并后再推送。 但是在真实的运行环境中，用户间协同并不总是会一帆风顺，只要有合并就可能会有冲突。本章就重点介绍冲突解决机制。 3.2.1. 拉回操作中的合并