共 7 篇相关文章
这篇讲的是作者为解决小米3手机无法连接Google Play商店的问题，摸索出的一套安卓手机代理翻墙方案。作者的电脑一直通过PuTTY连接海外主机建立的SOCKS v5代理正常上网，他尝试让手机通过同一局域网内的这个代理上网，却发现只有Dolphin浏览器成功，谷歌Play商店等大量应用依然无法连接。 问题的根因在于，部分安卓系统应用和商店无法识别纯SOCKS代理。作者最终找到了DeleGate这款开源工具，用一行命令将电脑上的SOCKS代理转换为HTTP代理。具体方法是在电脑端运行指令，将本地7070端口的SOCKS代理映射到8080端口的HTTP代理，然后在手机WLAN的代理设置里指向电脑IP的8080端口。 验证效果是，完成这个转换后，手机上所有应用都能正常联网，谷歌Play商店恢复了应用下载和更新功能。文章记录了从遇到问题、排查到最终找到可行解决方案的完整折腾过程。
这篇文章解决了一个挺让人头疼的实操问题：站长频繁收到 Google 站点地图警报，称 Googlebot 无法连接自己的网站，担心站点索引会被删除。 作者起初很困惑，因为他的网站服务器托管在香港，理论上不存在连接障碍。经过排查和咨询，问题根源被锁定在了正在使用的国内某知名免费 DNS 服务上。疑似该服务商出于商业策略，在境外访问上做了限制，导致 Google 爬虫无法稳定解析域名。 为了解决这个突发故障，作者没有简单地更换 DNS 服务商，而是提出了一个更稳健的方案：同时在 GoDaddy 上注册并启用两家 DNS 服务的解析服务器，将它们分别配置为域名的主、备 NS 服务器。这样做的精妙之处在于，它形成了一个解析冗余。通过 `dig +trace` 命令验证，DNS 查询结果有时从第一家服务商返回，有时从第二家返回。这意味着，当其中一家服务出现访问问题时，Google 爬虫还有机会通过另一家完成解析，从而避免了全天候无法抓取的极端情况，有效保护了站点的搜索可见性。 这个方案虽然违背了服务商的建议，但在实际测试中证明了其有效性，在解析速度和连接稳定性之间取得了理想的平衡。
这篇讲的是如何用 dig 这个强大的命令行工具，像侦探一样一步步揭开 DNS 解析背后的完整链路。作者从最基础的 dig 域名开始，演示了如何查询 A 记录、MX 记录等，但真正的亮点在于深入讲解了如何用 `+trace` 参数追踪从根服务器到权威服务器的完整查询路径，直观展示了 DNS 层级结构。文章还特别提到了如何检查 DNSSEC 签名信息、排查 DNS 缓存污染，以及通过 `dig @` 指定公共服务器（如 8.8.8.8）进行对比测试。 对于开发者和运维来说，这些技巧非常实用。当你遇到网站访问慢、邮件收不到或者想确认 CDN 配置是否生效时，掌握 dig 就能自己动手快速定位问题，而不是盲目重启服务。文章把原本枯燥的 DNS 协议变成了可交互、可验证的实操指南，让你下次再遇到网络异常时，能有一个可靠的“手术刀”来精准诊断。
这篇讲的是在 Erlang/OTP 应用中，一个看似简单的节点间 `ping` 调用失败，却可能涉及从应用层到网络层的多重隐藏问题。 作者从一个典型的故障场景出发：两个 Erlang 节点部署在同一集群，程序调用 `net_adm:ping/1` 或 `erlang:connect_node/1` 时，意外返回 `pang` 或 `{error, {badrpc, ...}}`。文章没有停留在表面错误，而是层层剖析了可能的“坑”。它详细分析了从应用层捕获的 `{dist, no_connect}` 错误信息，如何指引排查方向，并最终将问题定位到了网络基础设施——特别是 EPMD（Erlang Port Mapper Daemon）所使用的 TCP 端口（默认 4369）以及节点间通信用到的动态端口范围，被防火墙规则意外阻断。 文章的实用价值在于，它不仅点明了根因，还提供了系统性的检查清单与解决方案。例如，确认 EPMD 进程运行状态、检查并调整服务器防火墙或安全组规则以放行相关端口。这对于在云环境或复杂网络架构下部署 Erlang 分布式系统的开发者来说，是一次清晰的实战排障指南。
这篇讲的是，当你用ping命令发现到目标站点的丢包率居高不下时，该如何系统性地定位和解决这个令人头疼的问题。 文章从ping使用的ICMP协议原理讲起，点明了丢包的本质：数据包在从你的电脑到目标服务器的漫长旅途中，可能在网络中的任何一段“消失”。这可能是由于某台过载的路由器、一条拥堵的链路，或者是本地防火墙的拦截造成的。 作者的核心思路是引导你像侦探一样，通过“分段追踪”来锁定故障点。比如，先ping网关排除本地网络问题，再依次ping更远的节点，或者使用tracert命令来查看数据包具体在哪一跳出现了严重延迟或丢失。文章还提到了需要关注路由器状态、物理连接质量以及可能存在的软件策略限制。 最终，解决之道往往不在于单一操作，而是一套组合拳：可能是重启网络设备，调整传输窗口大小，也可能是更换更稳定的线路。这篇文章的价值在于，它提供了一套从现象诊断到根源定位的实用排查流程，帮助你在复杂的网络环境中，快速找回那个“失踪”的数据包。
这篇讲的是如何从零开始理解和配置Oracle监听器。作者从监听器拦截并转接连接请求的核心作用出发，深入解析了其配置文件`listener.ora`的结构与关键参数，例如主机名、端口号和服务列表的设定。 文章没有停留在理论层面，而是手把手演示了监听器的安装过程，并点出了安装后需要检查服务状态和配置监听注册。特别对动态注册与静态注册的区别做了说明，解释了为什么在某些场景下需要明确配置静态服务信息。 整体上，这篇文章把监听器这个数据库网络连接的“门卫”讲得清晰透彻，既覆盖了核心机制，也给出了可操作的配置步骤，对于刚接触Oracle或需要夯实基础的读者来说，是一份不错的实践指南。
这篇讲的是一个常见的系统小坑。作者在Windows 7下想用telnet命令，却发现提示找不到，以为需要额外下载安装。折腾一番后才发现，原来这个功能系统自带，只是默认没有被启用。根因在于Windows 7出于安全考虑，默认禁用了telnet客户端和服务。 解决问题的办法很简单，无需下载任何第三方软件。作者通过控制面板进入“程序和功能”，点击“启用或关闭Windows功能”，在列表中找到并勾选“Telnet客户端”，安装即可。这个方法同样适用于Vista系统，对需要快速用telnet测试端口连通性的运维或开发人员来说，是个省时省力的小技巧。整个操作过程只需几分钟，完成后便可在命令行正常使用telnet了。
