Tag Google

2018

使用 Caddy 配置 Google 反向代理

前面说到使用 Caddy 配置 Wikipedia 反向代理,其实平常用到更多的还是 Google,因此这里再来研究一下如何在 Caddy 上配置 Google 反向代理。 其实在用 Caddy server 之前我是一直使用 Nginx 的,作为一个 Nginx 用户,我更推荐使用 Nginx Module for Google ,这个插件,虽然安装起来有点麻烦,但是配置极其简单,效果拔群。 而对于 Caddy ,目前还没有太多现成的资料可以使用,好在配置起来并不是很复杂,配置文件如下: google.example.com { gzip proxy …

#Caddy#Google#反向代理

2012

慎用CNAME!

我的一个企业邮箱,从前两天开始突然不能使用了,准确来说,是只能发送邮件而不能接收邮件,发送测试邮件也总是会被退回,Gmail的退信提示说: Technical details of temporary failure: The recipient server did not accept our requests to connect. 很奇怪,前几天还用得好好的,怎么就突然不能用了? 刚开始怀疑是Google Apps的问题,因为我的邮箱是托管在Google Apps的,但是我的另一个企业邮箱却可以正常收发邮件,所以可以肯定Google Apps是工作正常的。 打开Google Apps的页面,提示我找不到域名的MX记录,这才想起来查看域名的DNS设置,但是仍然很奇怪,MX记录从来没有更改过,两个域名的MX记录一致,都是指向Google的邮件服务器的,怎么会导致其中一个不能使用呢? 这时,我才想起来,前几天将网站搬到了OpenShift,于是将域名的CNAME记录指向了OpenShift的域名,然后,然后邮箱就不能使用了! 会不会是域名的CNAME记录导致了MX记录失效呢? 我找到了这篇文章《域名别名CNAME的详细解释与说明》,验证了我的猜想。 简而言之,当我将域名A的CNAME记录指向另一个域名B时,邮件服务器传送邮件时,查询的便不是域名A的MX记录,而是域名B的。我将域名CNAME指向了OpenShift的域名,导致MX查询到的是OpenShift域名的MX记录,自然无法接收到邮件了。 所以,当我将域名的CNAME记录删除之后,邮件就可以正常收发了,这时候才发现漏掉了好多邮件啊!

#DNS#域名#CNAME#MX#邮箱#Google Apps

2011

Google Music初体验

在前一段时间的Google I/O上,Google正式推出了基于云储存的Google Music服务,但是一直没有开放注册,必须通过申请的方式获得Google Music邀请,然后才能使用这一服务。 虽然第一时间提交了申请,但是直到昨天晚上才收到Google的邀请邮件。 既然没有Android设备,只好在PC上使用Google Music了,第一次使用还会提示下载一个叫”Music Manager”的客户端,比较让人难以接受的是这个客户端目前只支持PC/Mac,再一次伤了广大Linuxer的心~ UPDATE:Google Music已经推出Linux客户端 其实这个客户端的作用无非是将本地的音乐文件上传到Google Music的云储存中,让人非常惊讶的是,在教育网的环境下上传速度还能达到一个非常理想的水平,不知道公网的速度如何呢?应该不会比教育网慢吧。 现在使用Google Music的时候还可以将Google提供的一些免费音乐添加到自己的音乐库中,歌曲很丰富,音质也非常不错,只是不知道这样的免费还能维持续多久。 将音乐添加到云端之后就可以在网页上直接打开收听了,速度非常快,几乎没有卡顿的现象,赞一个~可以在上方的搜索栏里直接搜索歌曲,还可以按照songs/artists/albums/genres进行分类。美中不足的是,由于编码问题(又是该死的编码问题),部分中文歌曲上传到云端后在播放列表里显示会乱码,不过鉴于Google Music目前还是在beta状态,而且也没有原生支持中文,也情有可原了。 虽然一直觉得把音乐上传到云端然后在线收听是一件很蛋疼的事情,但是这样做的好处还是显而易见的,比如我可以把Windows上的音乐全部上传到Google Music,然后在Linux上就可以直接听而不用挂载Windows磁盘了,甚至还可以在另一台计算机上听自己的音乐。而且,再也不用担心因为磁盘原因导致自己收藏的音乐丢失了~嗯,很棒的东西。 越来越喜欢云了。

#Google#Google Music#云

中文版Google也开始启用全新的导航栏了

今天中午登录中文版的Google Docs发现刚开始显示的还是旧式的导航栏,过了一会儿就自动更新为新版导航栏了 下午Google中文版的全系列产品都更新到了全新的导航栏,表示还需要一段时间去适应... p.s.仅限于Google中文国际版,谷歌(www.google.com.hk)目前尚未更新

#Google

[转载]用google.cn作proxy访问Google的服务

前两天为了能够访问appspot上网查找了很多资料,无意中找到了这篇文章,觉得很有价值,可以作为将来在Google服务无法使用且没有V6环境时的一个可选途径。 简单的说,Google的所有服务都是可以通过一个相同的服务器访问到,Google根据请求的URL当中的域名来决定应该定向到哪个服务。www.google.cn一样可以访问到所有的服务,例如App Engine。但是因为DNS服务器的原因,appengine.google.com会被定向到Google美国的服务器,不会去连接www.google.cn。但是事实上,如果我们能够向www.google.cn发送一个HTTP请求,其中的URL是指向appengine.google.com的,服务器一样能够帮我们中转请求,并把结果会传给我们。 要达到这个目的有两个方法,一个是修改hosts,让appengine.google.com和.appspot.com指向到www.google.cn的IP地址。这个有两个劣势,一个是www.google.cn其实有很多个地址做负载均衡,一旦加上了hosts条目,就失去了负载均衡的好处;另一个劣势是hosts文件不支持.appspot.com这种语法,所以只能把自己知道的appspot上的应用统统添加。 另一个方法则相对好一点,就是把www.google.cn:80设置成访问appengine.google.com的代理服务器。这种方法很好用,但是需要写PAC文件(Proxy Auto-Config,代理服务器自动配置文件)。所幸这个文件语法相当简单,因此可以直接写下面一段: function FindProxyForURL(url, host) { if (shExpMatch(host,"*.appspot.com")) { return "PROXY www.google.cn:80"; } if (shExpMatch(host,"appengine.google.com")) { return "PROXY www.google.cn:80"; } return "DIRECT"; } 然后保存成一个proxy.pac文件。在浏览器的配置当中,把“自动浏览器配置脚本”的配置项指到这里即可。 比如你把proxy.pac放在C盘根目录下,然后在firefox的“首选项”菜单中,打开“连接设置”对话框,选择“自动代理配置URL”,在后面的输入框中,填入配置文件地址,我这个就是file:///C:/proxy.pac对于IE浏览器,打开浏览器,选择“工具/Internet选项/连接/局域网配置”,随后勾选“使用自动脚本配置”项,最后输入自动配置脚本所存在地址即可file://C:proxy.pac 注意,一个是三个/,一个是两个/ …

#Google#GAE#GFW

appspot无法访问的情况下使用WallProxy

寒假在家上网的时候发现*.appspot.com的网站统统无法访问,虽然我已经将博客从GAE撤出来了,但是GAE上还放着GAppProxy和WallProxy,GAE的存活与否直接关系到能否翻墙,因此必须尽快解决这个问题。 但是在网上也没有发现appspot被墙的消息,因此怀疑问题出在我家宽带的运营商——中国联通。检查了一下电脑的DNS地址,是自动获取的运营商提供的DNS地址,将其更换为Google Public DNS,8.8.8.8以及8.8.4.4,果然,appspot又可以正常访问了。 可是好景不长,今儿发现通过WallProxy访问的网页又Error了,看来是appspot又无法访问了。 检查了路由器和DNS之后,确认这次是真的无法连接到appspot了,ping都ping不通了... 解决方案在此: 编辑WallProxy的配置文件proxy.conf,将其中的代理设置为‘proxy': {'http': 'www.google.cn:80'} 再试着通过WallProxy打开网页时,发现一切又恢复正常了! 但是此时如果直接访问.appspot.com仍然是不能访问的,我们仅仅是通过www.google.cn的代理去访问.appspot.com的,这其中的原理[这篇文章](http://www.douban.com/group/topic/9181172/)中写得很详细。 简单的说,Google的所有服务都是可以通过一个相同的服务器访问到,Google根据请求的URL当中的域名来决定应该定向到哪个服务。www.google.cn一样可以访问到所有的服务,例如App Engine。但是因为DNS服务器的原因,appengine.google.com会被定向到Google美国的服务器,不会去连接http://www.google.cn/。但是事实上,如果我们能够向www.google.cn发送一个HTTP请求,其中的URL是指向appengine.google.com的,服务器一样能够帮我们中转请求,并把结果会传给我们。 不知道这个方法还能维持多久,总之,现在又能翻墙啦~~ UPDATE:发现Hotot还是无法使用,因为我用的是自己在GAE上搭建的API,于是在Hotot里设置代理www.google.cn:80,问题解决。

#Google#GAE#WallProxy

2010

Google 开始测试搜索结果页页面预览功能

11月3日,我在使用Google搜索的时候发现可以每一条搜索结果的后面多了一个放大镜的标志,点击之后就会显示该条搜索链接的预览。 有图为证 然而随即该功能就被撤下了,可能是因为还在测试中吧。

#Google

我们需要什么样的即时通讯工具?

由于众所周知的原因,最近很多QQ用户不得不考虑使用其他的即时通讯工具(InstantMessaging,简称IM),而在众多的即时通讯工具中,我们该选择哪一个呢? 国产IM 代表产品:飞信,百度Hi,网易泡泡,阿里旺旺等等 国产的IM最大的优点是比较符合中国人的使用习惯,毕竟是中国人开发的~~但同时,因为XXXX(此处省略,你懂的)的原因,国产的IM的安全性不能得到保证,说不定哪天聊着聊着就被请去喝茶了...什么,不信?看看这个网站http://www.shcois.net/person_List.html就知道我朝的网络环境有多恶劣了。所以,能不使用国产IM,尽量不要使用国产IM。 国外IM 代表产品:MSN,Skype,Gtalk等等 先说MSN,这两天很多童鞋说要放弃QQ而转向MSN,MSN应该算是中国人最了解的一个国外IM了吧(很大程度上是因为微软),但是我确实很不喜欢MSN的官方客户端,安装包臃肿(离线WindowsLive安装包有155M),界面不够简介,广告数量一点儿不少于QQ,但是令人欣慰的是,MSN可以使用众多的第三方客户端,也就是说,即使你不使用微软的Windows Live Messenger,也可以一样聊MSN。这一点强烈鄙视疼逊,很多非常优秀的QQ客户端都被疼逊给封杀了,这也使中国网民养成了一个习惯:不管用什么IM,都习惯使用官方客户端,事实上只要稍微了解一下就会发现有很多优秀的第三方客户端可供选择,比如piggin。 然而MSN即使这样受欢迎,闭源的软件总免不了让人对其安全性产生怀疑,而且其数据采用明文传输,如果双方都安装MSN Shell开启加密的话应该会比较靠谱一点,记住,是双方都要安装! Skype我用得不多,主要是用它的网络电话的功能,Skype的网络电话还是很不错的。但是由于某种原因,Skype的中国版,即Tom Skype请不要使用,具体原因不解释。如果要使用Skype的话请翻墙上Skype国际网站下载Skype国际版,因为如果直接访问Skype国际网站的话会直接跳转到Tom Skype。如果仅仅用Skype进行通话和视频应该还是比较安全的,毕竟监控通话和视频的成本是很高的。 最后隆重推荐一下Gtalk,Gtalk是Google推出的服务,特点就是简洁!如果你需要一个IM仅仅是用来交流的话,那Gtalk再合适不过了。 正因为Gtalk的简洁,因而占用系统资源极少,并且经某童鞋测试,用Gtalk进行语音聊天不管是语音质量还是时间延迟都比QQ要给力得多,并且还支持将语音内容录制下来发送到你的Gmail邮箱了,是不是有点儿类似语音留言了?正是由于Gtalk与Gmail很强的关联性,Gtalk的聊天记录可以保存在Gmail里,这样就再也不怕丢失聊天记录了。 Gtalk的协议是完全开放的,因此除了使用官方的Gtalk软件(传送门:http://www.google.com/talk/)之外,还有很多很多的第三方客户端可供选择,这些客户端很多都可以支持多协议的,比如我现在正在使用的Kopete,就能够支持Gtalk,MSN,Skype,ICQ,等众多协议。也就是说,你可以在一个客户端软件上实现同时和N个IM上的好友进行聊天,是不是很强大? Gtalk支持的客户端列表 注意:如果你想要使用Google的官方Gtalk客户端,请务必使用英文版Gtalk或者Gmail邮箱里的Gtalk,因为虽然Gtalk有中文版,但是阉割了SendFiles等功能,最重要的是不能使用加密传输,因此使用英文版的Gtalk才可以得到最全面的功能和最安全的环境! 扔掉QQ吧,没有QQ,我们还有很多选择!

#QQ#Skype#MSN#Gtalk#Google#IM