Knighthana
Knighthana
文章97
标签140
分类7
回到首页
文章归档
关于本站

文章分类

文章归档

最新文章

© 2026 Knighthana Powered by Hexo & Nexmoe
网络连接问题及网络连接工具的问题集

网络连接问题及网络连接工具的问题集

2023年01月14日 Dev-Env

网络连接问题及网络连接工具的问题集

熟练解决网络问题是程序员们的必修课

安装proxychains4

直接通过包管理器安装proxychains会安装proxychains3，这是一个很旧的版本（其实能用；

不过我为了排除各种问题，例如解决软件过旧之类的疑虑，最后安装了proxychains4，也被称为proxychains-ng，这是一个最新的实现；

假如不慎和我一样，并非通过包管理器，而是通过下载源码并且以sudo make install的方式安装的话，那么在/usr/local/bin中可以找到它的程序，不过这种方式不受包管理器记录和控制，对于日后的维护工作来说不太方便；

另外，proxyresolv功能默认没有安装，需要自己从源码的src/中拷贝出来放到PATH中，我的话是和proxychains4的二进制文件放在一起了；

proxychains4的四种dns_proxy设置

可以从 官方带有说明的配置文件 中获取到关于各种配置的详细说明

  1. 不设置任何dns proxy项目，也即不进行dns的代理，这种情况下，被proxychains4代理的程序会擅自（可能程序自己不这么觉得）调用系统的DNS请求相关功能，查询自己要访问的目的主机的IP地址，交给proxychains4的是一个IPv4地址；(然后proxychains4将这个IPv4原样传给端口监听程序，那边没有识别出来，完美地走了通常的通道，仍然慢速甚至断流，鼓掌！啪啪啪啪啪啪啪)

    为什么不效仿浏览器，直接从socks5里面传domain-name过去，非要自己去搞那个什么IP-address？很好玩吗？

  2. proxy_dns_old模式，这种模式下，被代理的程序还是会发出DNS请求，只不过请求被proxychains4截获，并且用一个proxychains4程序自己的proxyresolv脚本代为办理了，但是可能我技术水平有限，目前发现这个脚本只能设置DNS_SERVER=，但是基于众所周知的原因，这种形式并不稳定；

  3. dns_proxy模式，这种模式会发送domain-name给对应的port，但是，某些老旧的程序和脚本，例如我发现的(也是最常用的场合)，oh-my-zsh的upgrade.sh并不支持这种模式，于是会卡在[proxychains] DLL init: proxychains-ng 4.16这条提示，天长地久，直到海枯石烂；(23/04/20：和ssh有关的话，可以怀疑是BUG导致的)

  4. proxydns_daemon模式，这目前是一个实验模式

    method 3. use proxychains4-daemon process to serve remote DNS requests.

    this is similar to the threaded proxy_dns method, however it requires

    that proxychains4-daemon is already running on the specified address.

    on the plus side it doesn't do malloc/threads so it should be quite

    compatible with complex, async-unsafe software.

    note that if you don't start proxychains4-daemon before using this,

    the process will simply hang.

    对于Linux内核版本大于等于5.9且proxychains4版本小于4.16-2(不等于)的使用者来说，如果要通过proxychains4使用ssh以及工作在ssh模式的git，就必须使用这个模式，

    因为新版本glibc中增加的new close_range syscall导致的此软件中close()钩子发生问题，而这个问题被修复的版本是4.16-2

    但是从描述中可以看到“however it requires that proxychains4-daemon is already running on the specified address.”，它需要一个搭档，否则不工作；

    更新：在 proxychains-ng 的配置文件中，它是第三种也是最不推荐的 DNS 处理方式。

    这种模式需要手动启动一个名为 proxychains4-daemon 的后台进程，并让它运行在特定的地址上。如果你没启动这个守护进程，proxychains 就无法拦截 DNS。它是为那些不支持多线程（不能用 proxy_dns）或无法运行脚本（不能用 proxy_dns_old）的极少数环境设计的。

被自己挖过的坑hosts文件坑

之前一直纳闷为什么某些请求始终是IPv4，起初以为是工具或者网站的问题，仔细一看地址再一回忆，原来我改过hosts文件。改回来就正常了。

将proxychains安装在MSYS2之类的环境中

proxychains-ng项目是一个UNIX项目，其中用到了诸如dlopen()之类的POSIX功能，而我在Windows下经常利用MSYS2创建一套熟悉的Linux工作环境，但MSYS2终究不满足POSIX，这导致我无法在MSYS2中使用这些好用的工具；

首先要排除第一个错误认知，就是make期间看到编译器报出能看懂的错误就觉得“这问题我可以自己解决”，一个成熟的项目，如果没有进行跨平台迁移就出现了make失败，那么问题绝不是几个.c文件和.h文件函数名称不一致这么简单，即便是移植，也要先看看有没有已经成熟的移植项目；

果然这个项目有一个Windows版本移植，不过用的是Visual Studio的那套SLN工程文件，但我根本不用VS，而对项目自带的MSYS版本和Cygwin版本的make不太顺利，在make文件中甚至用了-l$(xxVERSION)这样的方式进行链接，一旦xxVERSION为空，还得在脚本中一个一个找到链接指令对其进行修改；

还好项目已有二进制打包，只需要选择正确的二进制就能使用；

第二个问题，长期以来我对MSYS、MSYS2、Cygwin、MinGW的关系不太清楚，这导致我在选择软件版本的时候不知道要选什么；

我正在使用的是MSYS2-UCRT64，那么选什么二进制呢？

Cygwin是一整套兼容层，兼容层以上是完全的POSIX *nix，中间是一个我以前经常见到的cygwin1.dll，以下是Windows；Cygwin功能非常全面，在Cygwin上面甚至可以跑X11；

MinGW是一套编译工具链，众所周知C是自举的，MinGW提供了在Windows上运作的整套gcc编译链工具，而有了gcc，后面的就（可以认为是）都有了；

MSYS与MSYS2都是环境，它们提供了ls、make一类的指令，我以前之所以会把MSYS与Cygwin搞混，觉得他们两个平级，是因为以前使用Cygwin的时候，一直是通过MinTTY和apt-cyg操作整个cygwin环境的，这提供了非常类似于后来在MSYS2上的使用体验，毕竟默认情况下的MSYS2也是MinTTY，也有一个包管理器pacman（By the way, I use Arch），然而Cygwin实际上是一套非常完整的，提供了从基层工具链到顶层UI全部方案的“环境”，而MSYS2仅仅是用户环境而已，它需要一个MinGW编译链或是来自Cygwin的编译链；

顺便MSYS2里面也有一堆以编译链工具命名的环境，我让AI帮我整理了一下MSYS2网站上的说明，他们大概是这么个关系：

模式 (环境) 图标颜色 隐含意义 (特点) 运行库 (Runtime) 适用场景
MSYS 紫色 管理与辅助 msys-2.0.dll 仅用于 pacman 管理包或跑 Bash 脚本。不要在此环境下编译分发用的程序。
UCRT64 蓝色 现代 Windows ucrtbase.dll 当前首选。链接微软通用 C 运行时，兼容性最好，适合 Win 10/11。
MINGW64 蓝色 传统 64 位 msvcrt.dll 兼容旧版 Windows (如 Win7)。因链接旧版库，对 C99/C++ 现代标准支持略差。
CLANG64 浅蓝色 苹果/现代派 ucrtbase.dll 使用 Clang 编译器。提供更好的报错信息和 LLVM 工具链支持。
MINGW32 灰色 老旧 32 位 msvcrt.dll 仅用于维护必须在 32 位系统上运行的遗留项目。

反正Windows下搞新东西用UCRT64总没问题；

所以很显然我应该选择的是……Windows_x86_64版本——如果他能够在Windows下面被CMD或者Powershell调用，那么它就能够在MSYS2中运行；然而我想复杂了，在Cygwin版本和MSYS版本上浪费了许多时间；

这里顺便提一下，如果要在MSYS2命令行环境中安装gcc，不要直接pacman -S gcc，因为这样安装的gcc的Target:是x86_64-pc-cygwin，它会需要一些额外的动态链接库，而符合原本习惯的那种“编完在本环境中到处跑”所要求的编译链，应当通过安装mingw-w64-ucrt-x86_64-gcc来获取；

第三个问题，不要忽视DNS可能造成的问题；

关于这一点，备忘一下，不要忽视DNS，有问题的时候加个-v看一下解析了个什么玩意出来再作判断；

顺便，我错怪了某家网络巨头，我以为他们会粗暴拒绝cURL的请求所以才会导致断联，在排障后发现不是这样的，巨头不可能在乎这点三瓜两枣，对于他们来说商誉更重要，我属实是被抠门思想毒害了，在此忏悔；

最后，如果有什么只需要执行一次的环境代码需要执行，那么放在 

1
/etc/profile.d
比任何~/.bashrc或者~/.profile要强得多

总结

我还是需要找一些终端下更靠谱的工具，解决各种不稳定和断流的问题。

实在不行的话恐怕还得自己动手？

Knighthana

2023/01/14

更新：

修改了

proxychains4的四种dns_proxy设置

一节的内容

原因是：

ssh (and thus git) doesn't work anymore with proxydns and latest glibc #439

proxychains-ng doesn't work with ssh on Ubuntu 22.04

Knighthana

2023/04/20

修改了

我只知道它存在，但是没有找到任何有关这个东西的说明文档，

部分

原因是，其实是有说明文档的，位于GitHub: proxychains-ng/src/proxychains.conf

Knighthana

2023/05/02

新增了“将proxychains安装在MSYS2之类的环境中”一节；

修改了原先关于proxydns_daemon的描述，这并不是一个“新锐实验模式”，而是一个“用于对老式系统兼容而妥协的方案”，而在目前主流仓库已经更新到4.17版本的情况下，用proxy_dns的话简单许多；

Knighthana

2025/01/20

×